Worker<->UI communication is asynchronous, and has additional limitations (only copying, only JSON-able data), so synchronous worker API in many cases would just shift complexity elsewhere.
In part. It makes conditional, nested queries much simpler, however, when you don't need to nest async callbacks 20 layers deep.
I understand that having a synchronous API would mean more people would use it. But honestly, I see that as their problem. A fair number of queries, such as "select * from your_table where id = ?", are useful to have synchronous as an option, and should perform quickly enough to be invisible. And synchronous can easily be made asynchronous, but the other way around is essentially impossible without any Thread.join.
Except for Web Workers, also part of HTML5. The way Google Gears handled this was to allow synchronous database operations only in worker contexts.