It helps because apps are often used to view or edit files. By “files” I mean things like word doc files, photoshop files, Apple Keynote files. Many people like working with files and saving them locally, rather than on a server. With SQLite running in the browser, a file that is an SQLite database can be very easily read into memory, worked with, then saved back to disk. The page I linked explains this in detail. There are some examples of companies taking this approach at https://www.sqlite.org/appfileformat.html. Hope this extra detail is helpful.

Edit: Additionally, I encourage you to experiment with this. If you haven’t already, you may be surprised at how efficient/compact SQLite files are. They’re significantly more compact that JSON or XML documents and can include binary files like images. It’s much simpler to use SQLite as a file format than to create a custom binary file format.

This logic is flawed. X is not in Y, so we shouldn’t add it, because currently in Y no one is using neither X nor some crippled parody of it.

You haven't answered the questions. I don't see a reason to use RDBMS in a browser, if it's not, for example, an SQL tutorial site. You gave an example of a t-shirt store. A plain array of JS objects is enough to store items in a browser. Why do you need a fully backed RDBMS for it?

Because it’s a better programming model.

> better

Sorry, but it's just you opinion. Do you have proofs of how t-shirt store will benefit of putting RDBMS on a client side (how much space does it take BTW) instead of using simple list of objects?

And you still haven't answered the questions.