All the recent talk about systemd is about the other components that replace certain basic userland compoments.
logind for sessions changed the default to kill background tasks on logout, now it's about the implementation of the dns resolver that comes with systemd. There are other implementations that replace cron, ntpd, syslog...etc.pp. All of this has a dependency on glibc and uses dbus.
This has nothing to do with init scripts. This is an attempt to improve on the status quo of userland tools close to the OS. systemd appears to provide some minimal userland that comes with a Linux kernel and aims to be a userland API. I personally think this is a bad idea but I kind of see the point why you might want to do this.
The IMHO absolutely warranted criticism for some of these replacements is that they are not better designed, that they create new dependencies and complicate things without reason and there is a tendency to create some systemd specific API that userland has to implement - breaking compatibility with other POSIX systems - something that was hard to do even before systemd.
So it's not about init scripts - it's about revamping essential userland tools in a way that's badly designed according to some.
Personally I hold no grudge against this but I'm not keen on using this or having to deal with this as a sysadmin. It's a undocumented black box once you have run into problems and you are busy reading C code or capturing dbus calls. I have usually better things to do.
And for the initscripts - you could have done this with runit/s6 and mkdir with cgroups in 2008 if you wanted. You could have used setsid before that. This was deprecated and now systemd (or something else that implements the kernel API) is the whole mananger of cgroups.
I personally think the systemd way is not the right direction to take as it's horrible inflexible and will bite Linux but I can understand why you might disagree here strongly.