My experience is actually the opposite - every project I worked on that relied on an ORM actually benefited from replacing it with a clear architecture pattern and a query builder. Having the concrete notion of what is being passed to the DB allows easier debugging, and it is way easier to solve performance bottlenecks. As an example, recently I replaced several hundred lines of complex ORM oriented code with a 10 line CTE that would perform the iteration and calculation being done on the client side - the result was a 10x increase in performance with a fraction of the memory.
By not using an ORM, the developer also stops treating the database as a "black box". It is a "black box" conceptually, but the more you understand how it works, the better your applications will perform. As an example - knowing if, inside a transaction, when you're performing a read it comes from the server you just started the transaction or some slave that may or may not be updated (due to propagation delay) may seem picky, but its one of those things that is very hard to debug afterwards as a transient error.
Yes and no, it seems its an external module. And this is part of the problem - why would I need an external dsl extension to translate a pure relational concept into SQL? Debugging the query will require sql knowledge, regardless of ORM.In fact, the ORM is another layer to be debugged, it just adds complexity.