in the bad old times, every linux distro implemented its init scripts in a slightly different way, often with distro specific tooling and commands for accomplishing most management tasks

systemd unit files require minimal modification by distro repackagers.

With SysV-init, it was/is necessary to modify /etc/init.d/servicenamed shell scripts to get consistent logging and respawning behavior. With SysV init it's not possible to add edges between things to say that networkd must be started before apached; there are 6 numeric runlevels and filenames like S86apache, which you then can't diff or debsums against because the package default is S80apache and Apache starts with A which alphabetically sorts before the N in networkd.

And then add cgroups and namespaces to everything in /etc/init.d please

There were and are other options other than systemd and SysV years prior in fact. OpenRC and upstart predate it and s6 was not much later.

It's possible to pipe stdout to syslog through logger by modifying the exec args. But I'd rather take journald's word for it.

Supervisord (and supervisorctl) are like s6. I don't think any of these support a config file syntax for namespaces, cgroups, seccomp, or SyscallFilter. Though it's possible to use process isolation with any init system by modifying the init script or config file to call the process with systemd-nspawn (which is like chroot, which most SysV-init scripts also fail to do at all, though a process can drop privs and chroot at init regardless of init system).

systemd works in containers now without weird setup. Though is it better to run a 'sidecar' container (for e.g. certbot) than to run multiple processes in a container?

I (and this applies both with my dev hat and with my admin hat) can now write a unit file, depending on a different unit file, that works the same across all distros (note that this includes random end users whose systems I don't directly have access to). This even works for services that start per-user; no more write-only modifications to user startup files or DE-specific autostart dirs.

Pre-systemd this was unthinkable.

(similar stories apply to non-systemd-proper parts of the systemd project, but I personally haven't used them as much)