This is a rebuttal for Right conclusion, wrong reasons (http://bit.ly/oULuaz ) for an ORM being an anti-pattern.
The main purpose of an ORM (Object Relational Mapper) is to fix the object-relational mismatch, which is a mismatch between how an object is treated differently by the object oriented and relational paradigms which are fundamental constructs in programming and data storage/retrieval. The mismatch is well addressed by Scott Ambler of the Agile Manifesto (http://www.agiledata.org/essays/impedanceMismatch.html), Jeff Atwood of Coding Horror (http://bit.ly/pbImtX).
The traditional waterfall method handles this problem by trying to identify all entities and relationships before development begins. However the Rational Unified Process (RUP), Scrum and other agile development methods, however face a problem in that the data model changes, drastically during development, as more information becomes available and the client/implementation team learn more about the solution and business needs.
Hard-coding SQL statements becomes critical as these changes are not easily reflected as the database model evolves. ORMs like Hibernate (http://hibernate.org/) and Doctine (http://www.doctrine-project.org/) provide a means of mapping the POJOS (Plain Old Java Objects) and POPOs (Plain Old PHP Objects) into relational tables via XML mappings, and annotations (depending on your needs). As your model changes rapidly, all u have to keep changing is the database schema and object definitions.
The major strengths are also a big weakness, ORMs generate generic SQL which is not very optimized, so is slow when using traversing the object graphs, however a mix of ORM access (content pages, display pages where most attributes are displayed) and straight SQL (for lists and pagination) tends to reduce the impact of a the problem.
I have no experience in the new NoSQL data stores so I do not know what the implications are, but ease of unit testing, tool support etc, save time especially when the changes are rapid 🙂