For me it's solving the problem of simply and reliably wiring up persistent and resilient services (not shipped with the OS).
I don't know about you, but that's a need I especially have on servers.
When systemd works, it works remarkably well.
That aspect was already largely solved, and has been for a long time. runit, upstart, daemontools etc.
Daemontools, like a number of djb's tools, manages to really manage to blend an amazing level of "just works" and "ZOMG, I configure this how?!"
Have been using it since it was introduced in Fedora 16 (as I was a fedora guy) and I've never been convinced of its use on a server.
I understand it solves some problems but does so while introducing new and harder to remedy ones. (like tight ABI integration).
I don't mind systemd (ok, I'd criticise it but not nearly hate it as much), but I don't like that it's now the default target which forces me to use it in future.
I'm a Systems Engineer, so I have different needs from servers than Developers I guess, I want things to be easy to debug and diagnose.
I will say that I'm not only accustomed to systemd or sysvinit, I've also used runit at scale, along with SMF on Solaris and openrc.
SMF Beats the pants off systemd, even if it uses XML internally.