I realise it's slightly inflammatory to write a comment, but I'm genuinely a bit put out that Mozilla have decided to go like this.
This is how the process is supposed to work. Neither API is a standard yet. They are both at the "Editor's Draft" stage. Now is the right time to try to influence the eventual standard(s).
It seems like your main complain isn't relational databases, but rather the fact that the HTML spec, as stands, essentially specifies "whatever SQLite implemented" as its database specification.
So realistically, if we go the SQL route, what will get is SQLite. SQL is a great language and SQLite is a great implementation. But Mozilla knows what happens in the long term when we end up with a web standard that is actually defined by a single implementation: It becomes very hard for anyone else to implement the standard interoperably, or for the standard to evolve by design rather than by accident.
Programming languages are the most complicated standards of all. SQL is good, but Mozilla thinks it's better to give up the advantages of embedded SQL for a lower-level API that is more standardizable, and doesn't add another language to the web stack. (The language we have now - JavaScript - is just starting to be truly interoperable itself.) IndexedDB can and will be backed by SQLite, and the SQL language can be built back on at the JavaScript layer where it will be portable to both SQLite- and non-SQLite backends.
ActiveJS already includes a SQL parser/compiler in pure JavaScript for its in-memory datastore: http://activerecordjs.org/
Anyone telling me that they were going to implement their own SQLite (especially a browser vendor) and ship it to millions of users to run untrusted unsanitized input would get my door smashed into the face, their nose broken and bleeding. They would deserve it.
This must be a typo, becaus nothing is too much wank for the FSF. :)
Unfortunately, there is probably a Rule 34 for these things. Apologies in advance.
IndexedDB feels closer to real javascript - it does all access through javascript methods. Writing storage wrapper libraries will be cleaner against this kind of API than concatenating strings of SQL.
And it does not preclude someone from writing an SQL implementation on top of it, if they desire. (Or something simpler. eg. http://thomasfrank.se/sqlike.html)