I don't think it has much to do with the name. I think the biggest perceptual impact on SQLite came from Rails, and its default for using SQLite as a test database while strongly discouraging people from using it in production.
> By default, the configuration uses SQLite. If you’re new to databases, or you’re just interested in trying Django, this is the easiest choice. SQLite is included in Python, so you won’t need to install anything else to support your database. When starting your first real project, however, you may want to use a more scalable database like PostgreSQL, to avoid database-switching headaches down the road. [0]
Then most hosting for rails were stateless, so you had no way of storing SQLite on disk.
And finally, for serious production you need high availability and SQLite couldn't offer that.
Edit: I looked into a common Go driver for SQLite[1] and the FAQ reads,
> Can I use this in multiple routines concurrently?
> Yes for readonly. But not for writable. See #50, #51, #209, #274.
Every time I see a blog post from fly.io reg SQLite I'm tempted to use it for my next project, But the need to rewrite my framework for limited data types and the doubts regarding concurrency keeps me away.
When SQLite arrived it got lumped in with file storage that can't scale. Rails only perpetuated what everyone was already thinking.
SQLite is primarily embedded/local database and cannot be easily separated and shared over network [1] between multiple disposable backend/worker instances.