The binary log format has a huge advantage: it allows for arbitrary amounts of fields containing arbitrary content. Unlike syslog, journald is trivial to parse unambiguously, and you can even dump binary data like crash logs into it if you really want to. It also parses universally -- you always know what the timestamp is, you don't need to craft a per-service regex.
I'm not sure what would be a better alternative. I guess it could have gone with dumping JSON, but then you have issues with newlines, or escaping, and a single bad character can break parsing. At that point you might as well go binary, IMO.
If an application provides some standard command line tool that allows its internal data to be output as formatted text, then it in fact can be read with standard tools and manipulated with shell pipelines and scripts.
Plain text files are nice where possible, but binary formats are not automatically going against the Unix Way.
A well-designed, well-implemented binary log format? Quite possibly so.
Let's create a logging daemon that creates Apache Parquet files, for instance. Or at least uses a well-established, well-tested binary row format, with existing tools capable of easily unpacking it and working with it.
Maybe journald has a good enough API to stick to it. I hope it's going to be replaced with a saner implementation of that API, like Pipewire did with Pulse Audio.
I'm not sure what would be a better alternative. I guess it could have gone with dumping JSON, but then you have issues with newlines, or escaping, and a single bad character can break parsing. At that point you might as well go binary, IMO.