faster indexing
This seems too good to be true. You can only append to a log file, so you can't build an index, which means to search it you're probably going to be doing a binary search. Given text logs, what stops you from seeking to the middle of the file, seeking forwards (or backwards) to the next LF, and using the date there to pivot your binary search? You could go on about how that would need string parsing or something like that, but the choice of algorithm makes far more difference than a couple of extra bytes scanned one way or the other.
If you had text logs, you wouldn't need to parse it out to text - it would already be text. Want to grep logs? Go right ahead with the grep command, no need to invoke some silly log decoder to start things up for you. Corruption in the logs is still possible as with binary logs, but the difference is that logs are completely human readable and as a human you can probably figure out what type of corruption it is and can still glean meaning from the incomplete information.
At the moment I have a grudge against systemd's logging because it's completely stopped my user's journal for no apparent reason, and the guys at #systemd on freenode had no idea what was going on, and they said that to fix it I should wipe my /var/log/journal. That's a "reinstall Windows"-grade solution if I ever heard one, and it sounds like it will end in tears. What do I do after that, restart systemd? Reboot the PC? Recreate the directory, set permissions and reboot? Reinstall systemd? To make things worse, everything in /var/log/journal has been untouched for over half a year, so it isn't even keeping logs! Every restart, the new logs get discarded!
Apparently there's an option somewhere in systemd to turn on textual logging, but I haven't found anything of the sort yet. I also don't trust systemd to get textual logging right, since binary logs are its "usual" format and it gets that so horribly wrong.