(This is to OP rather than you)
Well if that's the argument he's making, one example I can think of, in the case of an extremely complex update, while it always can be done in pure SQL, it is much easier to logically code using an ORM, perhaps even using individuals rather than sets (the horror). And while this implementation might execute slower (.1 second vs .01 second), it is vastly simpler to read and refactor without screwing something up (ie: economically cheaper), and as for the performance argument, it only needs to be fast enough.
In respects like that, ORM's greatest benefit is also its greatest downfall. Using an ORM means you can put people who don't have a strong grasp of databases in charge of your databases. Sadly, it also means that you've put people who don't have a strong grasp of databases in charge of your databases.
For that matter, only needing to be "fast enough" is fine if you're the only kid in the playground. That's often a safe assumption to make if you're writing app code, but less so with databases. If the database is being shared by a number of applications, or if the server is hosting multiple databases, or if you have to worry about concurrency, then being "fast enough" probably isn't enough. Because you've also got to think about all the other ways that your queries could be affecting everyone else, and making sure you aren't subjecting your server to the tragedy of the commons.
Which comes to another nice thing about having a dedicated database person. It means there's someone whose official bailiwick is the DBMS. If app A isn't experiencing any performance problems itself, but is causing performance problems for app B (say, because of some perverse locking situation), that's a bug that a DB guy is best positioned to diagnose and fix. If the application isn't too tightly coupled to the database (i.e., sprocs are in place) then he can even quietly fix it on the server side without having to hassle anyone about the application code. A team that's too ORM-reliant, on the other hand, risks failing to include anybody who's even well-equipped to recognize the problem, let alone fix it.
There is a really interesting post about how writing that code is literally stealing from your clients. I tend to agree. http://ayende.com/blog/3712/stealing-from-your-client
This is not true.
At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model. If your hand is not forced by the ORM, this is unlikely to be a direct mapping of the database.
This is no different than a network protocol, wherein the protocol is not a direct representation of application state, and the application does not attempt to model the network protocol using the same constructs that it uses to model its in-memory state.
...and that is where you have just created an ORM. You don't need a library to be using an ORM. Change 'extract' to 'map' and the meaning is the same.
What if it's better structurally for the program as a whole to think about individuals?