While that's true, I also think that the current rage is stateless applications, outsourcing state to centralised database/cache/object storage layers over a network connection.
That allows you to easily spin up/down e.g containers, migrate the application between nodes etc without having to maintain a high performance network file system.
Using sqlite in such an environment requires you to either solve the persistence layer in general (≈ rook/ceph) or specialised for sqlite (≈ litestream/litefs/rqlite depending on your need). I think one probably could argue that rqlite is essentially a network protocol for sqlite.
This really depends on what you mean with "application". It is very popular to have the "backend" stateless, yes, but it is also popular that each service has their own dedicated database, and to consider the service/application to be the combination of the stateless backend and the dedicated stateful database.
The application is stateful even if the backend is stateless.
While that is very true, I think my point still stands.
Even if you consider the application to be the combination of stateless binary + stateful auxiliary services (like a database), the statelessness of the binary allows for some neat things.
I replied to a comment talking about how network based database access is not necessary, and I think it very much is if you want to host stuff with the current popular architecture. Unless you implement a general shared persistence layer on which you can run e.g sqlite, but that dosen't seem better/easier to me.
That allows you to easily spin up/down e.g containers, migrate the application between nodes etc without having to maintain a high performance network file system.
Using sqlite in such an environment requires you to either solve the persistence layer in general (≈ rook/ceph) or specialised for sqlite (≈ litestream/litefs/rqlite depending on your need). I think one probably could argue that rqlite is essentially a network protocol for sqlite.