As far as I am concerned, the only legitimate reason I have heard for using object relational mapping (ORM) is if a switch to a different database engine is probable (not just possible). MySQL to Oracle would be an example (although I don't know why anyone would desire to make that particular change unless they absolutely had to). And even in that case an ORM may not be the best decision.
I heard one reference that bothered me that suggested that it is less competent programmers that are against ORM. One could just as easily say that it is programmer incompetent in SQL that are in favor of ORM. So lets not make that type of argument.
Reasons I am against ORM is that I believe it takes away from transparency and makes it difficult to make the inevitable ongoing tweaks that are a major part of all development cycle. If a developer is not fluent in a particular ORM and is hired and needs to make a database change, a task that would othersize take an hour could take many hours. So "rapid" application develop becomes "crippling" application maintenance.
I also believe that complex design patterns where one language automatically writes another language should be generally avoided. ORM isn't the only example of this, of course. Another example is PHP that writes out XHTML. Note every line of code we write needs to be be or should be object oriented. Embedding our markup language and query syntax rather than having our programming language "automagically" do it makes the application more transparent (easier to understand), debug, and maintain. Also, some may say that an ORM "frees" projects from the constraints of a particular database engine. But what about the constraints of your new "fadish" ORM engine? You can pretty much guarantee that the major database engines will be supported longer than most ORMs.
I would also like emphasize that ORM is not VMC, although a lot of VMCs are bundled with ORMs. It is perfectly valid, and I think desirable in most circumstances, to create models that contain hand crafted methods with hand written SQL.
I would also like to dispell one other myth--that ORM are connected to RAD or rapid application development. I do not buy this because in my personal experience I only spend about 10% of my time writing SQL and crafting models for CRUD. So even if ORM cut this time in half (and I don't think it does) then it would only be a 5% increase in my development time (which it isn't). And I'm not an SQL expert or DBA either--just a developer with average SQL skills. SQL is just not a big time sink as long are the DRY principle is followed and models are created with intention.
I personally believe there is a lot of "group think" around ORM--that developers say it should be used because everybody else says it should it be used; it's considered a "hot" technology that one can pad a resume with. Put it on your resume if you feel you must, but but don't use in an important project just because you feel you "should."