It's not that SQL queries are difficult to compose, it's that ORMs enable different abstractions to emerge, at least when used appropriately; I'll admit though that junior developers are drawn most to ORMs because they limit exposure to SQL. I'd recommend you check out a legitimate ORM that implements the Data Mapper family of design patterns such as SQLAlchemy or Hibernate.
(Incidentally, DataMapper in Ruby doesn't in fact implement the Data Mapper pattern, which I find irritating.)
I think ORMs do a fine job, excellent even. The problem is that you may be using O's which require a lot of M'ing to from the R's ;)
So if you don't do mainstream OO, then you probably don't ever need ORM. SQL databases are powerful relational engines in their own right - many ORMs have to replicate a lot of that functionality into their memory based stuff (which can be good, but its more work).
I guess its all slowly fading, as I am led to believe the trend is away from relational data to distributed data, which has a different set of problems...
I'm using Haskell + CouchDB. The bindings are simple enough that I've been able to hack fixes for them pretty easily, and just as importantly, Haskell's GADTs are much easier to translate into JSON than they are into SQL rows (at least I thought so). Turning around, you can spit JSON back up at the web layer after some mapping, filtering and processing, so it's not as if you'd wasted effort by writing JSON instances for your data.
The complaint was that there aren't any mature libraries that go a step further, beyond feeding manually-constructed query strings to the DB connection, preventing injection vulns at the type level, etc. In an OO language this would be an object-relational mapper. I think the functional crowd is still trying to figure out what a "functional-relational mapper" is supposed to look like.
Seriously, how hard is it to compose a SQL query?