The biggest problem with ORMs is the same problem I see with OO frameworks that generate public accessors for member variables.

Accessors for member variables turn objects into glorified structs. When you design an object's interface, it really should be in terms of messages, not in terms of what guts the object contains.

SImilarly, ORMs map each column into the interface, instead of mapping the interface from the use cases. Surely, you could create "actual" objects that encapsulate that, but I don't see that happening very often (even in my own code).

What happens when the DBA decides that street address should actually be two fields: street number plus street name? We now have to ripple that through all the code, because all the code was talking directly to the street address text field before. Sure, we can do some wrappers and things, but a proper OO design would have minimized the locality of that knowledge. ORMs don't encourage that design.