In my experience, DBAs go into seizures when they hear a developer say "they don't care" about the database. I actually challenge the assertion I always hear that ORM takes less time to develop with. Up front, possibly--but people lose sight of the hidden costs of the increased complexity.

There is (and remember time = money):

-Time to setup the ORM solution, troubleshoot if problems (likely)
-Time to learn to use the ORM tool
-Difficulty of finding someone who knows the ORM tool you use (vs finding anyone who knows SQL...)
-Additional cost of paying someone to learn or ramp up to learning the ORM tool you use, if needed
-Time required to tune performance
-Decreasing quality of support over time for the particular version of your ORM tool, as new versions appear
-Time required to upgrade your ORM tool if needed because the version you use is too far out of date to get adequate community/pro assistance when needed
-Loss of entire database-specific features that a SQL solution designed by a DBA would have been able to take advantage of, due to the attempt of ORM to be "database independent" (which is rarely even needed)
-Possibility of bugs in the ORM tool, and time lost tracking these down if they occur
-Performance penalty of using the ORM tool
-Additional cost of hiring more highly skilled maintenance programmers to maintain ORM applications, vs hiring more entry level programmers who know SQL
-Increased demand on application server memory and processing requirements
-Minimization of database caching, in favor of ORM tool application server level caching--a particularly interesting topic when in a multi-app-server environment (heck I've even heard that some ORM tools don't update the database immediately, essentially making data in the database stale when accessed via a different application server)
-Inability (or additional time required?) to fine-tune queries to not pull back unneeded data (vs sql, simply select fewer columns)

This isn't a trivial list of downsides. There may be a few that have good workarounds or tools that don't have the problem, but saying ORM is obviously "better" than a non-ORM solution is just plain hogwash. Even in the situations where it works well and doesn't impose too much additional cost, it's almost impossible to say that a non ORM solution would have taken any longer.

But I'm thinking that I'd prefer to skip all forms of ORM entirely, even "manual" mapping via SQL. At the end of the day, it's just extra work that could be avoided, yet this 400lb gorilla is never noticed. (To continue the primate analogies.)

If you're using an object oriented language, really it's about time we (as an industry) should be switching from RDBMS to OODBMS object databases like db4o or Objectivity/DB. Instead of all this ORM crap, we could just be typing: store(someObject); (etc) and be DONE. Or just use a non OO language and use the RDBMS more logically. Why are we doing this mapping nonsense? Sorry this turned into a rant.