I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.
I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.
If a package you develop relies on only systemd's init capabilities, it'd probably be pretty straightforward for someone to port it to an OS with a different init system (like BSD). If your package relies on other systemd capabilities, though, the task of porting gets much harder.
Such as? Which other "systemd capability" besides the init system part exposes an API to general user-space applications? The only one I can think of is logind, for which an alternative implementation (elogind) exists.