With systemd you still have to fiddle with symlinks to enable/disable units (at least on the same level as other init/rc systems which have wrappers around ln).

With systemd you still have to fiddle with symlinks to enable/disable units (at least on the same level as other init/rc systems which have wrappers around ln). And with a sane RC system, such as OpenRC (which technically is still SysV init, but who cares about the init process.. it doesn't do much really), I would argue the scripts are on the same level of complexity as systemd unit files for most cases (so it would be fine to use either). But for more complex applications, such as mounting crypto devices or network configuration, these two do depart a fair bit. Systemd chose to not go the way of simply wrapping the cryptsetup command, but talk directly to the kernel, which would be fine or even better in theory, but has the slight drawback of reducing (as far as I could tell) all error conditions to Invalid Argument (which took me then quite a bit of effort to find out what I had done wrong). Systemd-network(d?) suffers from the same problem (doesn't use the iproute2 command, but directly speaks to the kernel) in my opinion - again it is only really useful for the most common use cases, uncommon ones become impossible (because certain iproute2 features are simply unsupported as of yet) or really difficult to debug (because you are debugging an application interpreting configuration files instead of simple shell scripts).