I think the author missed one downside in that there is no master/slave replication built in. That's not the biggest deal as it's relatively trivial to dump the DB elsewhere on some regular schedule, but if you want to minimize the effects of a server dying, it's hard to beat built in replication.
That's not quite the same as you'd still need to have some way of exposing the database on a different machine. You could use NFS or some other network storage, but that's kinda hacky and doesn't deal with network failures well. (In fact, that documentation doesn't specify what happens if one database file becomes unavailable while you're attached to it at all.)
There are work arounds, of course, but I think it's a pretty big downside that it's difficult to set up robust replication with sqlite. It's certainly one of the things that cause people to say that it's not a "real" database.
You can also just (eg) copy the backing file wholesale. It's portable and endian-agnostic. I guess it depends on exactly what you're trying to do and what guarantees you're requiring.
I totally agree, I just thought it was odd that the article didn't mention it. There was a section on when SQLite might not be appropriate, but it never mentions this. Easily avoiding data loss is a huge feature for a db that's going to have any amount of production data, so if you're proposing that people use SQLite for production workloads, this should be acknowledged.
