Ted Neward recently slammed object/relational mapping technologies. I have a lot of respect for Ted, so it was interesting to read. It is nice when your beliefs and work get slammed by someone whose opinion you respect. It keeps you honest =)
I think what Ted describes isn't object/relational mapping, though. He describes sunk-cost driven design and career driven design, and assigns the blame to O/R mapping. There is definate validity in the example of O/R mapping as driving SCDD, as rolling-your-own O/R mapping framework seems to be even more popular than writing blogging software or IRC bots (I blame PoEAA). As another more famous guy writing O/R tools has said, O/R mapping is hard to do well.
Its entire premise is that it is an edge case designed to handle the sharp bits. A lot of people go into using an O/R mapping tool expecting that using it is like pulling object references out of a really big in-memory hash map. It isn't, and I doubt it ever will be. Transparent Persistence is a marketing term (that means "lie"), it isn't. However, because you need to spend far less effort on persistence you tend to really want it to be true, and code as if it is. It is much like Sun's laws about network programming. You cannot pretend it isn't there when the libraries make it too convenient.
I recently gave a presentation (sorry I cannot post it =/) looking at when and where it is appropriate to use different styles of persistence in Java: tabular, entity, and transparent (misnamed). Interestingly, entity systems are generally the most successful in my experience, simply because they force the programmer to consider persistence. They don't offer much over a sophisticated transparent solution in terms of speed, scalability, or power, but they affect programming style more, and don't let the programmer "forget" that the object is persistent.
An interesting pattern I have seen in the use of O/R mapping is that a team will start using persistence Project A, which will solve everything for them. They write a bunch of gnarly code, and along the way learn about how O/R mapping works. The project fails miserably as the team didn't understand the technology, and learned as they went. As it is always easier to blame the technology than the people, Project A is labeled as crap, and they switch to Project B. Knowing the constraints of the tool now, and having better expectations, they have miraculous success with Project B. I have seen this across lots of pairings of tools, and both ways, depending on which is used first. I have seen this pattern in more than just persistence, but this is about persistence.
Probably, what we all need to do, is to remove the word "transparent" from "transparent o/r mapping" and admit that it is simply a high level tool, be up front about the design considerations, and talk a lot more about how to design applications using these tools rather than what the tools can do.