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.