>>You can do systemctl list-unit-files
Sure, but how is that an improvement over locality-of-behavior and having unit files in easily known locations? Here's a rough list of places you can find unit files:
#Places you can find systemd unit files
/etc/systemd/system/*
/run/systemd/system/*
/lib/systemd/system/*
...
$XDG_CONFIG_HOME/systemd/user/*
$HOME/.config/systemd/user/*
/etc/systemd/user/*
$XDG_RUNTIME_DIR/systemd/user/*
/run/systemd/user/*
$XDG_DATA_HOME/systemd/user/*
$HOME/.local/share/systemd/user/*
/usr/lib/systemd/user/*
Now if you simplified that list you wouldn't
need to learn a new tool and either memorize or look up a bunch of arguments. You could just have a sane directory structure and use some path globing.
With a bit more work (or possibly just a different balancing of priorities, with more care taken to locality of behavior) I think you wouldn't need some other tool.
I think you're really missing the point here, unix (the philosophy, not the implementation) is a programming environment. Yes, systemd has created tools to let you do most of the things you used to be able to do using standard tools, but there's a big difference between having a tool box and having a program feature.
A more complicated example, inotifyd is very useful, how could I go about triggering a script every time a log file is written to under systemd? When you start looking at these tools as part of a cohesive programming environment than you start to see systemd as full of edge-cases you have to account for. Lets say I want to count how many times a particular event appears in a log (quickly and easily, this isn't production) and send it to my cellphone. In unix-philosophy I can add something like this to my inotifyd-tab, `grep "some-event" | wc -l | pushbullet --push my stream`. How could I do something like that in systemd-land?
>Do you prefer the old init system because it is something you are used to (and do not want to change) or do you have specific instances where systemd is broken for you ?
I can see you're already dismissing the "unix philosophy" complaint, and really that is where I'd like to focus. Systemd will keep getting better in most cases, so that fact that I've had frustrations with it in the past isn't really a big deal. I'd be willing to deal with that if it was actually, you know, better than something like openrc.
But since you've asked, here's a non-exhaustive list of points that I've been frustrated enough to actually document them. I imagine a lot of them have been fixed by now.
Years ago I wanted to run debian on a kobo ereader. Unfortunately the built-in OS image was not running systemd, and the kernal was several revisions out of date. While I had no problem getting a debian chroot running, all of the services were designed to run under systemd, this made the whole project much more of a pain in the ass than it should have been.
By default systemd will kill long-running processes when I log out. Processes like screen or tmux. This has since been resolved, presumably by my distro somewhere, but took a solid while to figure out when that behavior suddenly changed.
When troubleshooting a raid array using a mipsel processor, I had persistent network issues. I took the boot media out for trouble shooting, but when I ~~chrooted~~ systemd-nspawned into the host to try to address the problem, I discovered that journalctl would segault. Thankfully /var/log still had all the entries I needed to fix the problem and binary logging wasn't enabled, or that would have been a much bigger problem. This appeared to be a general issue with running journalctl using qemu-static and binfmt.
For some reason my mother's computer can no longer resolve DNS. Ripping out systemd-resolved seemes to have fixed it, but not before I lost a few more hours.