Disclaimer: My experience comes from ~8 years ago, but ORMs were commonplace even that time. Not sure what improvement happened since.
An ORM framework gives you a false promise: that you can forget (or not even be much aware of) that you are working with a DB, and just continue using objects the way you normally would in your programming language (my experience was from Java).
That is a lie, and lies will come to hurt you eventually. Some specific examples that hurt me back then:
The promise that it is easy (no fiddling with schema, DB connections, whatever). Initial wiring is always a hassle - getting the configs right, getting JPA to register correctly, getting the annotations right. Not as worry-free as expected.
Leaky abstraction. For example, when you commit new objects to the DB the first time, their identity changes (see developer.jboss.org/wiki/EqualsAnd...).
Where are transaction boundaries? If db objects mix with regular objects and get passed around in code, it is easier to loose track of what is committed or not (or when). Usually what you want is doing logic upfront, then having a tight section where you make a transaction.
Limited performance. The ORM can't do as sophisticated query optimization as the DB can.
Unexposed DB functionality. Eventually you might need something from the DB that the ORM doesn't expose.
My choice is having a DB access layer, which exposes high-level operations to the user code, but implements db access using SQL directly. I believe it is a low-friction and clear solution.
Besides, writing huge joins is fun!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.