Because an SQL engine that defers control over connections, concurrency, storage, and process management to users is extremely valuable for multiple reasons, including simple cases like caches where you'd ordinarily just store things in flat files or BerkleyDB-style database, and complex cases like distributed statekeeping where existing SQL databases aren't going to do anything close to the right thing for your application, but you also don't want to reinvent SQL and query planning and write-ahead-logs to build your complex database.

The vibe I get from this thread is that a lot of people have only experienced SQLite from the vantage point of something like Rails running in a "test" environment, and are used to explaining to people on some PHPbb somewhere that you can't really use SQLite to back a multiuser SAAS app. That's as may be, but when you're building infra components, you control who the "users" are; not everything is a web server taking requests from all comers.