Its not a big deal in Hibernate. SQL can be logged. You can intercept everything. And you can use sophisticated monitoring (e.g. New Relic's APM). To me, debugging with an ORM like Hibernate was never more complicated than debugging with the JDBC driver.

Also, ORM implementations often contain multiple layers of abstractions, even co-existing ones (JQL vs. HQL). Personally, I don't like HQL / JQL. But it does a good job for simple tasks. For more complex things, I can write SQL and use just the mapping features of my ORM. I rather use Hibernate to get things done, than writing all the boiler plate with plain JDBC.

I think that depends heavily on the ORM in question. ActiveRecord's SQL can become nightmarishly complicated but the same query in DataMapper looks alot like what might be written by hand.

ActiveRecord is way more expressive than DataMapper, IMHO, particularly if you want to make a fancy query GUI, and it's because of the additional abstractions it builds into its SQL generator.

Actually, I've found it's generally quite straightforward to enable logging of the SQL executed by ORMs. What I have found difficult is trying to untangle the mess of inefficient SQL and coerce the ORM to doing what I really want it to do :/

Change the verbosity of the logging statements. They'll always output what SQL is going on.

It's fairly easy to do this in Entity Framework. Obviously if you have a giant query it's going to make some "optimizations" that you don't like but if you have a good understanding of your object model and how your database is architected you can usually create nice SQL.

The real problem is that the object side is less abstract than the SQL side.