> you're almost surely not using any kind of fsync's in your plain-text logger
I am, though, and have been for many years.
* http://untroubled.org/daemontools-encore/multilog.8.html
* http://b0llix.net/perp/site.cgi?page=tinylog.8
> you're almost surely not using any kind of fsync's in your plain-text logger, so that text file isn't as incorruptible as you may think
Agreed. But if the log file is corrupted, then a plain-text one will be easier to decipher for a human than any binary blob.
Writing to files in general is a fairly difficult thing if you care about not losing any data under any circumstances, because you have to use the right syscalls for the semantics of your filesystem, which may somtimes be why you're looking at corrupted files in the first place.
Correctly implemented transactions can prevent you from dealing with that. Maybe that's worth giving up easily readable, searchabe and processable textfiles, maybe not.
Given the extensive testing including crash testing, it's plausibly more robust than plain text - because you're almost surely not using any kind of fsync's in your plain-text logger, so that text file isn't as incorruptible as you may think. And you may write a buggy logger, or use a buggy json implementation, or write incorrect error-recovery code when reading the file.
I'm skeptical that robustness is an argument in favor of plain text logging over sqlite.