I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.
Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?
Good questions. The reasons are complicated, but I will try as best as I can.
When journald was made it was constrained by several design parameters: it should have total backward compatibility for those needing this, it couldn't require that any userspace program should be rewritten in order to work with it, including syslog implementations like rsyslog. It should simply be a drop in replacement, giving people the opportunity to use its enhanced features if they wanted to, or just use the usual rsyslog setup they always had used. It should also be as simple and fast as possible. In fact, the journal more or less an append text file with other newline delimiters and an added index.
And because journald worked with syslog, people could use rsyslog for all their advanced database logging needs. In short, journald makes it flexible for those who have advanced needs, instead of tying them down to a particular solution. Unlike rsyslog, journald isn't a log sink (and hopefully never will be).
All in all, making sweeping and complex changes like using a real RDBMS as a logging back end wasn't an option. Also, such RDBMS solutions already exist in a mature state in e.g. rsyslog, so there was no need either.
There are other design constrains concerning logging on Linux. At the moment everything goes into /dev/log, and only one program can read it a time. AFAIK, you have to rework both the way the kernel does logging and user space loggers in order to have more than one program reading log info from the source. The solution seems to requires using kernel namespaces and other low level systems, and are likely to require that both kernel version and user space loggers are synced to a certain version in order to work.
So AFAIK, it isn't easy to make a early-boot-log helper that hands over logging to syslog when it is done, at least not in a lossless way and certainly not if the helper logs are meant to be incorporated into the syslog flat text files (which is why eg. dmesg is a separate log file).
As for logging being "married" to init, the main argument was, that in order to have first class service and process management, you need a matching first class logging system. In order to have early and late boot log messages, the init system have to be aware of a lot of low level system stuff, and cooperate extensively with the logging system. They could have used rsyslog and changed it so it worked like the journald works, but that would have tied all systemd Linux distros to a particular syslog implementation.
Having them working together also makes it trivial to attach log messages to a service check.
Are binary log files a necessity of the systemd design? Absolute not. But then again, people who prefer flat text files for logs can just use rsyslog/syslog-ng as they always have. The binary log files are optional. But the binary, structured and indexed journal log do solve so many limitations of flat text files that I am glad it exist as an option. The systemd journal really is a joy to use.
