This argument presupposes that using simple DBAL and/or some custom SQL does not allow you to keep your concerns separated (false), and using an ORM greatly simplifies and/or vastly speeds up development (also false, sometimes in the short term, always in the longer term).

Personally, I find SQL queries, relational models, foreign keys, etc. to be much easier to reason about and understand than allot of the abstractions that ORM's create. I always have to parse the documentation again when thinking about the "owning" side and gotcha's associated with that.

Additionally, the queries are always about one order of magnitude faster using something like PDO instead. Even 7 table joins can be very snappy in straight SQL. On my dev box, with all caching turned on, like in production, ORM queries take about ~15-25ms for a run of the mill, one table insert, retrieve, or update. The equivalent PDO query is about 1-1.5ms. Further, through the natural course of development, ORM's result in about a 10x increase in the number of database accesses (usually invisibly) over a simpler PDO solution. Developers can't help but navigate the ORM object graph. If they do it in a loop, we're really screwed. At that point they may turn to DQL, because it's the normal thing to do. But DQL is almost SQL and what have we gained but a sub-par SQL? I will tell you. We now have a third level of abstraction to keep in our heads (SQL, vendor-specific DQL, vendor-specific ORM). Once we start talking an order or magnitude (or much more) difference in performance, then it behooves us to take notice.

Obviously, writing a ton of custom queries for repetitive CRUD and run of the mill queries is not efficient. So, we have code that abstracts all of that away. Code to create a row in a newly created table takes about 2 minutes to write using a light PDO abstraction wrapper. I know ORM's give that same functionality via annotations and what not, but it isn't that much faster to write. Sometimes, it is slower (e.g. custom column name mappings). But, the one thing we don't do, and indeed the main root cause of the ORM performance issues in my mind, is represent the database in code as a connected object graph accessible via getters and setters.