To add a little: systemd is just a service manager. It manages services.

You can plug systemd-journald into it and now it does logging too. Or you can use rsyslog, or both together, or something else entirely.You can treat your network connections like services (technically units) with systemd-networkd. Or you can use NetworkManager. Or both, or neither, etc.You can treat mount points as units because somebody said "let's define mounts in a new kind of unit file and have systemd initiate them as a service" or you could continue using fstab.You could use systemd-resolved but you don't have to. You could use systemd-udevd (you probably already do because most distros run it by default, though it still pulls from /etc/udev) but you don't have to.These are all optional extensions.

It turns out it's really handy to have a robust service management backbone because you can plug any number of things into it, as long as you reimagine those things as services (again, technically units).

So what's the controversy?As far as I can tell, it boils down to "they shouldn't have made systemd-networkd only be able to talk to systemd, they should have made it work with every possible init system".Which is understandable, but not really defensible.