"Unfortunately, these advantages disappear as the project increases in complexity: the abstraction breaks down, forcing the dev to use and understand SQL"
"Forced" to use and understand SQL? I think you have a basic misunderstanding of the purpose of ORMs, Laurie. The developer who can't use and understand SQL really has no business going near the ORM. They probably need to stay somewhere near the front-end doing design, layout and UI-centric work.
The purpose of an ORM, properly used, is not at all to completely remove SQL from the developer's toolkit, but to help developers who fully understand SQL and Objects eliminate boilerplate SQL. This has a huge dual benefit of productivity boost plus elimination of bugs by the reduction of code/SQL duplication.
If an ORM developer is not aware of SQL (i.e., watching their rails log for odd queries/joins) and the natural problems that arise, such as n+1, etc. then they probably shouldn't be writing data-layer concerns. ORMs are for experienced developers who know how to use things like the ActiveRecord or DataMapper DSLs when appropriate, and can also drop into straight SQL when appropriate. ORMs are power tools for serious developers who can use them for what they do well, and know how to avoid their weaknesses, which you outline well here.
Because of their benefit and the cumulative experience we've had in the last 10 years or so getting to know how to use ORMs effectively, they're not going away any time soon. However, they certainly have their pitfalls and it's important that we have posts like these every few years or so to remind us what those pitfalls are. So thanks!