Every browser maker was interested in implementing it but the W3C couldn't go ahead with it because everyone chose to implement it using SQLite, where as W3C required more than one db back-end implementation to move forward.
If that's all you need, it wouldn't make sense to include SQLite in the browser. If you're going to include a relational database you might as well use it
The original slow IndexedDB implementations were done that way, but my understanding is that anything fast and "modern" probably isn't in 2020 as most of the browsers moved to their own IndexedDB storage implementations that are not SQLite-based. IndexedDB has very different expected performance characteristics than a pure relational DB (as it is a key/value store with indexes closer to most "NoSQL" DBs than to SQLite) and it did not (and does not) make long term sense to use SQLite below the hood.
I often wondered why someone didn't do it with BerkleyDb too? I know Oracle owns it, but it is open source and someone like Mozilla could have implemented it in their browser just to get the W3C rolling on WebSQL.
Every browser maker was interested in implementing it but the W3C couldn't go ahead with it because everyone chose to implement it using SQLite, where as W3C required more than one db back-end implementation to move forward.