As mentioned, I understand the advantages of said system, but I still prefer the transparency and simplicity of "raw" SQL statements.
SQL is an abstraction layer, and one that is documented in hundreds of books and articles. Well, all depends where do you want to draw the line. Raw sql allow you to define what do you want to do with the data. It becomes a burden if at some point you want to tinker with that precise logic. In drupal we are already doing something like that in a few places - db_rewrite_sql being the example in core. flexinode, cck, views do that as well. db_rewrite_sql is the most hairy example. I still refuse to read that particular function.
We do sql templates as well, via the db_query syntax, but that may not be enough. All of previous suggestions - arrays, function helpers, mini languages can be employed one way or another if there is really a big need for them - that is they really simplify the development by raising the abstraction and the flexibility of the code, help with code reuse, including db queries, and don't cause big performance degradation.
I, for one, wouldn't want to learn an application specific SQL-like description language. As a developer, it would sorta turn me off, and make me shout 'bloat!'. I wouldn't either :)