Is ORM still the "Vietnam of Computer Science"?
Yes.
Object-oriented is still object-oriented and Relational is still Set-oriented. Nothing has changed in these two paradigms in the past two years to make them work better together.
In many people's eyes, SQL is ugly, complex, and confusing. But trying to make an object-oriented interface to perform the same functionality is always uglier, more complex, and has a steeper learning curve.
In all programming, there is a tradeoff between flexibility and assumptions. Frameworks (such as Rails) try to solve the problem by being "opinionated." That is, they limit flexibility of either the relational or the object-oriented aspects of the problem, making assumptions about how data is structured, and what operations you can do with it. Naturally, simplifying the problem space makes the solution simpler as well.
In addition, it's frustrating to discover that an ORM framework is incomplete, so some ordinary operations in SQL have no solution in a given ORM. This is also a consequence of "opinionated" frameworks.
It's still true.
Even more than OO software, the database suffers if it isn't treated precisely the way intended. And it wasn't intended that you should interpose some abstraction layer in front of it.
I think of impermeable abstraction layers as trying to build a Lego castle with all the pieces closed up into a pillowcase. SQL is damn hard to do correctly. It doesn't share many patterns with procedural programming, and best practices for one can be the opposite for the other. You need to be able to grok every single item in a SQL statement, and have a pretty good idea what it's intended to do, and what it in fact does.
Lots of people seem to think that, like horseshoes, close is good enough - if the right answer pops out, that implies you're nearly there. In SQL, that's simply not true.
RoR and the ActiveRecord pattern have deservedly earned a reputation as dbms resource hogs for this reason. Optimized ActiveRecord design is more often than not suboptimal SQL design, because it encourages SQL statement decomposition.