What I've seen many times with ORM tools is blind interaction with the in-memory object graph abstraction over the data store which results in many un-needed queries. It's like the option of making one DB query which returns a flat result set isn't even on the radar.
As far as I can tell Factories have been replaced with DI frameworks or just hand rolled DI.
Singletons aren't so bad if you're working with an object oriented language and the singleton is just an instance of a service which holds no state and has methods that operate on a limited number of data types. At that point it's essentially just a namespace for a functional library.
Observer/Listeners ... Not sure here unless the commenter is advocating message queues or eventing.
Most applications copy a string from here and paste it over there. Input, processing, output. What we used to call data processing.
Add some defensive programming for sanity. Validation rules, "schemas", type systems.
Favor composition over inheritance, a useful programming language over "dynamic typing" (aka type hostile).
Extra credit for logging, monitoring, auditing, alerts, rolling deployments.
Life time victory achievement bonus award for setting breakpoints (debuggable) and easy reproduction steps.
---
Instafail if you use mappings (eg ORM), observer/listener, factories, singletons.