They are using asynchronous queries still, and the problem is that they aren't always asynchronous if there are any long-running queries happening in the background. That's the reason for the hang per the most recent bug.
If temp tables were causing problem, then there's something seriously wrong with SQLlite's in-memory temporary tables (or how they are being used). By definition they shouldn't be blocking...
Firefox was creating memory-backed temporary tables and syncing them to disk; however, the process of regularly syncing to disk while using the browser caused issues. It also added to start-up time requirements.
For example, if you don't want to hold the entire history in memory but only the most recent changes, you have to create a view spanning the temporary table and the on-disk table to do history queries (so the Awesomebar returns results from pages you just visited, as well as ones already written to disk) and things get complicated.
Define "regularly", he's talking about 15 minutes. I don't know that I'd even want it done that often. This is not critical data, let the filesystem layers do their job, at which point the RAM used by keeping a (very small, in any event) working set cached is also irrelevant as the filesystem cache takes over.
If temp tables were causing problem, then there's something seriously wrong with SQLlite's in-memory temporary tables (or how they are being used). By definition they shouldn't be blocking...