Having sqlite included in all browsers with standard bindings would have been great.

It would! But it would also be a security nightmare. Exploit SQLite and you could use it in Safari, Chrome and Firefox - everybody could be affected.

How would that be different from someone editing something in window.localStorage?

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

I think that meant: How would that be more of a security nightmare than some malicious site editing your browser's whatever.localstorage?

Ironically, all the IndexDB implementations were just thin layers on top of sqlite last I checked.

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.

This could work if there is a subset of SQL where duckDB and SQLite behave almost identically

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.

The problem with WebSQL would remain the same, it would be necessary to specify a subset of SQL as a web standard.