IF ORM's stuck with the 80-90% case I don't think people would have problems with them. Unfortunately, they try to handle an ever wider range of edge cases which tends to create complexity and cruft. As soon as I need to double check their output and I see horrible gobblygook for a moderately complex query I am generally better off writing it myself than trying to understand how I can get the ORM to make a cleaner query.
Still, ORM's seem to be getting better Linq to Entity Framework seems to work much better than a lot of the old ORM's I have used.
ORMs don't try and handle anything. People apply them poorly which simply creates bad code.
The same can be said of the goto statement, or any number of other things - used improperly, they screw up everything, but in some instances they are necessary and good.
Actually, that's not really true. An ORM will almost always attempt to convert your object access to SQL. It's not always possible to make it work as well as a rewritten query. For instance, sometimes you need to use an EXISTS, or change a join order with a hint, or find a better way of reducing the driving table's rows to get better performance.
With an ORM, no matter how much tweaking you do, it is sometimes impossible to get the performance that a well written SQL query can achieve. And that's not because of bad code, or that the ORM is a bad choice.
BUT...those are problems that an ORM is not a good tool for. If someone is trying to use an ORM for that, that's the programmer's fault, not the tool's.
Still, ORM's seem to be getting better Linq to Entity Framework seems to work much better than a lot of the old ORM's I have used.