In my case, we had a need to keep the datatypes and queries tightly coupled to their specific use cases, largely for the sake of performance. So we were using a strategy along the lines of what's described in the "result-set-based relational mapping" section of the article. But over time it started to feel like the data access layer was turning into one big example of the softcoding anti-pattern.

So the code's been going back toward just writing the routines for dumping results into objects in application code, and we're finding that this does seem to be more maintainable. And it's definitely proving easier to reason about bits and cycles without this big (trying-to-be) black box right smack dab in the middle of everything. Not to mention that having to think in 3 languages is more than 50% harder than having to think in two.

ETA: I'm beginning to think that last bit defines the difference between ORM success and ORM frustration. If your needs are such that can largely avoid the SQL, then you can largely stick to just reasoning in the application's programming language and the ORM's data mapping language. One anecdote that I think supports this possibility is that ORM proponents see the ability to easily flip among different RDBMSes as a big bonus. Whereas folks who aren't fans tend to see it as a sign that the DBMS isn't being used to its full potential, since advanced SQL features (and basic rules of thumb for designing performant schemas) are almost always very DBMS-specific.