I just read Martin Fowler's ORMHate post, and I must agree with him. I was skeptical the first time I used an Object Relational Mapper, but once you get used to them, they are fantastic.
Just a brief review of what an ORM is. The basic function is to convert a relational table database into objects automatically for use in your application. So your user table with it's associations to user posts (for instance), can be turned into a user object with the ability to fetch user post objects. This is great, because it avoids the need to spend large amounts of time creating repetitive code to access your data and turn it into objects. As Martin pointed out though, you do need to put in some time to make it work exactly right with your database. Once you have this interface, you can create an application much faster, because you don't have to spend so much time building the base access layer.
I do think that Martin missed a few points that are important though. There are several pitfalls that I have seen that a developer needs to be aware of.
The first and most important, in my opinion, is being aware of what the provided calls actually do with regards to the database. For instance, how exactly does the count call work? Does it get all of the objects from the database and then count them, or does it use the built in count function in your database? A good ORM would use the latter, but developers should find out for sure. Another example, and unfortunately I can't find the article, comes from an article I read about someone profiling their application. They noticed there were two nearly identical calls to their database. The first was to find out if there were any records meeting a certain criteria. If there were, then the second call would fetch those and return the data. Obviously, you're making two calls for the same data, but they didn't know the check worked that specific way. The solution ended up being a flag to tell their system to return an empty array when no results were found, instead of false or null.
A second pitfall would be forgetting how to write basic SQL or just interact with a database. I think all developers that are writing code interacting with a database should feel confident working in a SQL command-line. Not for bragging rights or anything along those lines, but because it will help you write better queries. Knowing how long your queries take, how your database is actually laid out, and what unnecessary data you may be getting can lead to optimized queries, saving money. If a developer can use the database less or at least more efficiently, the database doesn't have to scale up as much. With one of the clients I worked on, I was able to take another developers query from 5 seconds down to 200 milliseconds by removing a join that was unnecessary in a certain context. That's a huge savings in resource usage. (The 5 seconds mainly comes from an awful database design, but that's a whole other post).
One final pitfall is when your original developer leaves, and the existing/new developers are only left with an ORM. They may have little understanding of why certain database design decisions were made, or be completely unaware of them. Again, I encountered a system that had two ways of determining whether a user was on the email list. One of them was a legacy from before even the previous developer, but I wasn't made aware of it when he left. The obvious opt in flag was inaccurate for those accounts. Confusion ensued, because the ORM did not account for those columns. They were set to not be included in the models. Suffice to say, I thought they were deprecated/legacy and had already been dealt with. Surely they were just there because no one had bothered to drop the column. Not to mention the column name was less than descriptive. This could all be written up as a lack of documentation, which is true, but it is still something that should be taken into account with ORMs.
Definitely don't take these as reasons to not use an ORM. They are well worth it. These are just warning signs on the road to make developers aware of things to think about. "Bridge ices before road" seems obvious, but you would be surprised how many people don't think about it.