For example, you can make sure some poorly written python daemon will never use more than 50pct of the cpu or over 1 Gb of ram - and systemd services will nicely restart the daemon if\when that happens.
By not using systemd you are depriving yourself of essential tools in modern sysadmin (timers alone are worth switching to systems compared to cron anachronistic hacks)
Them being released at similar times does not mean systemd implemented them, they exist completely separately to systemd.
Literally:
mkdir /sys/fs/cgroup/memory/<groupname>;
echo 100000000 > /sys/fs/cgroup/memory/<groupname>/memory.limit_in_bytes
I've been charring my brain to understand what you mean by this.
You don't need to have cgroups for all applications in order to use them.
And they don't need to be implemented by systemd specifically for them to be in use by other init's or tools.
SystemD existing (and being pushed so heavily) stymies the rise of such init systems.
Adjusting to systemd took me a while, but I believe it was worth the effort, and I also believe most people who dislike systemd are just set in their old ways
All the initial "ooh and aah" factor of SystemD came from using the kernel's cgroups mechanism, which was a dumpster fire by itself--something dropped by google in the kernel for easier maintenance with the understanding that no one should be stupid enough to use it for something important...enter SystemD.
Apparently cgroups is in better nick these days (as is SystemD), but until the likes of Al Viro come around and give it a clean bill of health, I think I'll pass.