I suspect this fuels some of the hype--trying to correct the misconception.
You have to be able to architect your application to send all write traffic to a single process and have a language that can keep up with your database while doing that. There are "better" architectures for this stuff now that will enable that which have come together in the last few years, and a resurgence in smaller indie projects willing to deploy sqlite on servers and do weird cool things like this fiddle or datasette
Counter-point: sqlite's sister project and SCM, the Fossil SCM, is a self-hosting sqlite client application and has been since 2007. Every hit on the fossil-scm.org website is its own standalone fossil process accessing the same copy of the same db file, all while the developers are actively pushing and pulling changes to/from that same db and while half a dozen or so folks are logged in to its /chat room (each instance of which is long-polling that same db 24/7).
In 14 years of using that db i've encountered _maybe_ two locking errors.
Similarly, sqlite3's own forum is a fossil instance hosting a single sqlite3 repository.
That all writes "have" to be channeled through a single manager is demonstrably not the case.