ORM systems are highly complicated abstractions.
Most of your developers will use them without understanding how they work. In many cases, the only way to understand how they work is to read the source code.
They have magic features that are advertised as convenient but when they inevitably do something you don't want them to do you'll tear your hair out trying to circumvent them.
They put lots of complicated weird stuff in your stack traces so when something goes wrong with "the database stuff," which is probably going to happen every day, you will feel confused and overwhelmed.
ORM was famously referred to as "the Vietnam war of computer science" by Ted Neward. [2]
There's a point that I think is even more important than the unruly and bewildering complexity of ORM, but I'm not sure I know how to formulate this point.
One way to formulate it would be to point out that your dichotomy of two choices is missing an alternative, so I present:
3) Code your data access in a separate module exposing query & save functions that make sense within your domain model.
In a reasonably complex system, this module might consist of fifty functions that concatenate SQL strings or whatever. In most cases, I'd bet money that rewriting this module to support some other data storage—especially if there are integration tests—would be easier and more pleasant than switching your ORM and then dealing with the random problems that will inevitably occur.
And when some query fails or is slow, the developer issued to fix it will just go into the file, find the query, and change it. It's simpler, there's less obscure technology to worry about, fewer things to get angry at.
[1]: http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
[2]: http://blog.codinghorror.com/object-relational-mapping-is-th...