The major point of systemd's binary logs are that they are both structured, indexed, and contain rich meta-data, something plain syslog logs isn't.
That again means that when you export your logs to a log-sink, you can do so in a format that fits directly into the log-sinks database like JSON format and preserve the rich meta-data like the "_MACHINE_ID" field, that uniquely are tying every log-entry to a certain machine. You can also be sure that that the program claiming to generate the entry actually is correct since journald provides kernel guarantee for this.
If you choose to keep the logs in journald's binary format on the log sink server, you gain the benefit of indexed fields when analysing data; a huge win when it comes to random access. So much faster than trawling through text logs (O(n) complexity and all that).
Every log entry can be traced back to a certain machine (not just hostname), many log fields have kernel guarantee for what they say, besides having integrity checking and even strong cryptographically "forward secure sealing" (FSS) security against tampering.
The journald logs are simply designed from the ground up to be read an analysed on other computers than the one they were generated on, either in their native format or as exported logs.
Since the journald can be accessed programmatically, it can aggregate and analyse logs across different languages and has strong immunity against changing wording of the daemons log output (it operates on fields, not words).
And since the journal logs are structured identically by a documented standard, they are trivial to aggregate, unlike the output of many different syslog implementations.
Since the journald binary logging file format is stable and fully documented, and can be accessed programmatically with language bindings, you don't need a specific binary like "journalctl" to read them. In fact, there are there is a Rsyslog module that allows it to directly read (and export with metadata) systemd journal's. There are also Python modules etc. that acts as journal readers etc.
In fact, it is quite possible to make a systemd journal reader that works on non-systemd platforms like MS-Windows or OSX.
The journald collate all logging on the Linux machine, that means everything can be trivially exported to a remote log-sink, including the kernel ring buffer and the binary utmp and wtmp log files that syslog doesn't know about, and it can include early boot and late shutdown log info because it can work in initramfs, something syslog can't.
How about journald being designed as signal-safe from the ground up (unlike syslog) and that it doesn't silently drop messages under load etc. etc.....
systemd's binary log format is simply a massive win for both the enterprise user and the Linux newbie and everything in between.
The arguments against it are based on contrived scenarios, like professional admins that doesn't have (systemd) boot medias and lack access to a pc, a usb stick and a internet connection so they can make one in 5 minutes.
All the standard Linux text tools like grep, tee, sed, sort etc. work with systemd's journal through the Linux/Unix concept of piping.
Sure, systemd's journal still doesn't have as many tool sets and projects around it as syslog. But that it is simply a matter of time.
