journald? The log where corruption bugs are considered[1] NOTABUG? That on its own is enough reason to stay away. Pretending that log parsers don't exist makes this a nasty case of "not invented here". Use that risky mess if you want. I'm sure it will work great in most cases. Just remember that some of us value stability and a proven track-record more than fast searching. Especially when log parsers give us the fast…
I think you've misrepresented the bug. "when reading we try to make the best of it" -- that sounds like they've done their best to work around files that are corrupted externally, not that journald is actually corrupting logs itself.
The source doesn't matter, because corruption happens. Bugs happen, hardware fails, attackers try to cover their tracks. The bug I (and the original reporter in this bug report) are referring to is journald's behavior when corruption happens: shove the log aside and start from scratch. Even worse, the attitude that ignoring corruption is "not a bug" is insane.
Yes, fixing a corrupt binary database (even a simple one) is going to be very hard. What they fail to mention is that the reason they are face with this difficult problem was their decision to use that kind of format in the first place. When faced with the realities of their bad design choices, pretending there isn't a problem is not the correct answer. The correct way to handle that bug report should have been either fixing the bug (make journalctl able to handle corrupt logs), changing previous bad designs (drop the format that makes this a problem), or at a bare minimum recognize that this is a serious problem for some people and leaving the report open if it cannot be fixed right now.
Given that this kind of external corruption has a very good chance of being the very reason you have to search the logs, how a logger acts in that kind of situation is of key importance.