There's an argument to be made for picking an existing standard. I probably would have, were I developing something like systemd, because I'm lazy. But, the path they've chosen is more flexible than that, and has some other benefits. syslog is a very old standard, at this point, and has
many limitations and issues, particularly in a world where a deployment might involve hundreds of instances of a service.
Lennart wrote a pretty good summary of why journald exists, and I think it holds up to scrutiny pretty well:
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...
One could argue about what the right "one log" target is, but I doubt one would come up with syslog. syslog-ng and rsyslog were incremental improvements, and solve some of the issues, but they're 18 and 12 years old, respectively, and both pre-date containers, widespread cloud computing (AWS came in 2006), service-based architectures, etc. When they were new, we still had servers that did one thing.
One can also argue about whether journald is the right implementation, even if we acknowledge that a new standard is needed, we don't have to agree that journald is the right one. But, I wasn't writing the code, and what they came up with is pretty good. I don't have any major complaints about it, except that I have to learn some new stuff.
So, I respect the argument that they should have chosen an existing standard for logging, but I also see the reasons why they chose to build something new. I think if I'd been involved in the decision, I probably would have come down on the side of journald, in the end (but would have needed some convincing).