Intermediate solution: SQL command text that generates the configuration file. Command text goes into source control, and the database it generates gets deployed.
Its not about the quantity. For my application the key driver was incremental remote update. If your deployment model is that 100% of the application configuration is linked into the container image, then I can see how flat files sound appealing. I completely agree with Dan Luu about the perils of files, though[1]. My application is a remote sensor that both requires incremental update, and is large enough to justify SQLite over something smaller.
I don't think much of that Dan Luu article applies to read-only files deployed with the application, which is often what configuration files are.
Definitely concurrency control is an issue with mutable files, that would all by itself make me hesitant to use them as a storage solution if that were in play. But it's not when the changes to the files are being done outside of the app being deployed, and they are deployed as read-only, any changes require app restart to pickup etc. That is how I have usually experienced configuration and I have personally never run into any problem with having it in the file system.
Most of the other stuff in the article also seems to me not to apply to the standard configuration use case.
(And if it did... it would apply to your source files too, right? Whether ruby or python or even JVM bytecode. Yet we obviously can and do put those in the filesystem. Ultimately read-only configuration are just another kind of source file they don't really have any special problems).
But "incremental remote update" (without requiring app restart especially!) is definitely not the standard configuration use case. I agree that a 'real database' seems reasonable for that use case, whether sqlite3 or something else. Whether you try to control the configuration (that will wind up in a db) in your version control system, or just use standard db backup/clone techniques instead.
cat my_configuration_text.sql | sqlite3 my_configuration_database.sqlite
Closely related, sqldiff ships with sqlite. It generates the difference between sqlite database files as a bunch of {insert,update,delete} statements.