What about the very common cases where you need to do very simple things, like common CRUD operations? Abstracting the SQL required for these simple queries makes a lot of sense to me.
Sql is designed exactly for CRUD. Almost by definition there's no better way to do CRUD than sql. And about CRUD - most software should rightly be CRUD, because CRUD represents the highest level of abstraction in programming that you can get (below natural language interface of course). Sql CRUD abstracts away all hardware and software layers of the computer (the only hardware/software efficiency decision you have to make is where to declare indexes).
It doesn't abstract away the fact that your application is written in terms of polymorphic objects, rather than opaque relations. It also doesn't abstract away the fact that people like to represent their data with data structures richer than "set". SQL works reasonably well for CRUD, but most web applications are not CRUD, they're online transaction processing, where relational databases just get in the way. A good object database is a much better fit. (And no, I don't mean CouchDB.)
