I know this has been a long-standing area of debate and has been discussed to death, but I just have to get this out of my system since it's bugging the heck out of me.
We use DBIx::Class on our project. It's a great ORM. For my last job, I chose Rose::DB because I needed the performance. I've recently heard that they're ripping it out and replacing it with DBIx::Class -- for performance reasons. Allegedly all of the hacking I had to do to get classes to share database handles (it doesn't by default), support transactions and force all attributes to be private by default slowed it down to the point where it offered no speed advantage. I never saw the benchmarks, but I put a lot of work into ensuring that Rose fit our company standards and now other programmers are putting a lot of work into replacing it. So that's lots of work on things which are only indirectly productive.
I should add that while I have been generally positive about ORMs in the past, I keep seeing the difference between theory and reality. Most projects I've worked on which have heavy ORM usage keep fighting against the ORM, but few question whether or not it's the ORM itself which is the issue. When thinking about ORMs, the end goals we should focus on are:
For many projects, I think the ORM inhibits achieving either of those goals.
The problem, of course, is how to deal with these issues. One common strategy is to push the domain logic into the database. This is very powerful because it leverages the database's strength of data management and makes it hard for a developer to forget about business rules. Unfortunately, MySQL severely limits our ability to do that. For example, we cannot define custom types, check constraints are not available and triggers are extremely limited.
Another strategy is to develop a solid domain layer which truly represents our business processes. Underneath can be a variety of strategies such as SQL dictionaries, limited ORMs with direct database calls or anything else we think of. The key is to have that domain layer which insulates us from the implementation and gives us the freedom to focus on business needs rather than picayune details of how to write a left outer join with a subselect in our ORM of choice.
The question, at its core, is whether or not ORMs offer the maximum return on investment. While the answer isn't the same for everyone, I get tired of watching projects scale upwards only to discover programmers constantly working around ORM issues.
A large part of the problem, however, may not directly be the ORMs. It may be the affordances they provide. For example, Mason is a great template system. It's very rich. It's very powerful. Every company I've worked with which uses it pushes far too much business logic into their templates. This is because it's a simple and natural thing to do with Mason. Template Toolkit, on the other hand, starts with Perl and passes data to the templates. While you can push too much logic to the template layer, it's less natural and, from what I've seen, less common.
ORMs may be the same. While extremely powerful, they may make it so easy for developers to operate in a certain way that they fail to consider alternatives.