I'm not even going to get into a pro/anti systemd argument becauser that's actually not relevant here, but this is why people get annoyed with the systemd folks, because of the mindless zealotry/ignorance. No offence, but solutions to this have existed for YEARS and have been implemeted in plenty of other systems.
Really, please show me a non-systemd Linux distro that doesn't use scripts for setting up daemons and boot, thereby mixing code and config statements in one unstructured code lump that are hard to parse for both humans and machines. And does it provides high level API abstractions for cgroups and kernel capabilities so SA's can use them for all daemons just by adding a simple key/value line in a text config file?
I am well aware that SysVinit and endless variations like it such as OpenRC exist. But they don't provide any meaningful competition to the many features that systemd provides. You may be happy with SysVinit and its many limitations, but I and so many others aren't.
If you don't recognize how superior systemd is to existing alternatives, you also say that no new development is necessary for the non-systemd distros in order to stay competitive. I would like to see some real competition to systemd, but it doesn't happen, seemingly because the systemd-opponents have dug into their own grave claiming that everything existing is good enough and systemd is just bad. Shrug.
You have a text based log file, which just works with everything. You also have a separate binary index which indexes the textual log file. You get the benefit of fast lookup if you use the index and it will just work no another machine if the original tanks and you don't have the right version of systemd on the new machine.
You really are uniformed about systemd's journal; its structure and layout and API have been fully documented and is stable. That means you can read any journal with any systemd version. At worst you may miss out certain extra meta-information fields that have been added later, but nothing essential will be missed (and it will be information that any text based syslog implementation won't have anyway).
The systemd journal is designed to be read on other machines, and it does it exceedingly well, like reading from nspawn OS containers, etc.
Plain text log files have been a problem for Linux for decades, and many projects, including Rsyslog was started exactly to overcome the many limitations with both the syslog interface and the plain text log files.
The current journal file format, which is basically an appended text file with index, is a great compromise between having unstructured, unindexed text logs with no meta-data, and running a full sql-server.
If the non-systemd distros have a better idea, then great, let them implement it, but I fear the usual answer will be that text logs are the final word in logging, and that no new development is needed.