The biggest systemd fault is one of tooling, and that just comes from a project ambitious enough to try and own it's own ecosystem.
When runit/daemontools, you "debug" a service by typing:
/path/to/service/run
With systemd, you run a unit file by copying it into a directory and run some (magic) commands. You need training/internet search to learn those commands. If your unit file doesn't work, you need more training/internet search, but systemd is still so new that your best bet may be to read the systemd source code, or insert a hacky "sleep 30" at the top of your start script and try to race and strace it in another window. Stuff like that.
Want to upgrade your systemd unit? You can't run it along-side an existing version of itself unless you give it a new name, which changes how journalctl can pick up the results. Versioning in the unit name feels wrong, and nobody does this yet which still currently breaks live upgrades where the unit changes.
Eventually the tooling will get better, but then we'll have a way to read files, and away to read systemd files; we'll have a way to run programs, and we'll have a way to run systemd programs; we'll have a way to "test" units, and a side-by-side mode, and so on.
Another way to do this is pam_ssh_agent_auth. Been using it to authenticate to sudo for years on systems that only maintain keys and no passwords.
I used to use runit/daemontools/inittab. My favourite thing about systemd is that it is increasingly available, and while it has it's faults, it has instances (macros you can use to kickoff a fleet of services easily) and pretty good isolation features.
It also has a "systemctl-over-ssh" feature which is quite nice, and which allows you to use an .ssh/authorized_keys file instead of sudo to allow access to certain administrative tasks.