I think journald is by far the buggiest component systemd has. Log corruptions, the dubious Forward Secure Sealing mechanism, journal file fragmentation, the gateway daemon, coredump hooks. There's been several CVEs for it, too. Of course, you cannot disable it without source code modification.
Quoting from the systemd wiki [1]:
Note that it is now the journal that listens on /dev/log,
no longer the BSD syslog daemon directly. If your logging
daemon wants to get access to all logging data then it
should listen on /run/systemd/journal/log instead via
the syslog.socket unit file that is shipped along with
systemd. On a systemd system it is no longer OK to listen
on /dev/log directly, and your daemon may not bind to the
/run/systemd/journal/syslog socket on its own. If you do
that then you will lose logging from STDOUT/STDERR of
services (as well as other stuff).
...unless your syslog implementation is socket
activatable many services will not be able to log to your
syslog implementation and early boot messages are lost
entirely to your syslog implementation.
So the fact that keeping your regular syslogd wasn't as simple as merely symlinking syslog.service was publicly known, but often overlooked by proponents during discussions.
Quoting from the systemd wiki [1]:
So the fact that keeping your regular syslogd wasn't as simple as merely symlinking syslog.service was publicly known, but often overlooked by proponents during discussions.[1] https://wiki.freedesktop.org/www/Software/systemd/syslog/