Just an example of systemd limitation is that systemd does not support musl, so if you want to build a tiny embedded sysroot, you already have some limitations.
OpenEmbedded has carried a patchset to build systemd against musl for use in Yocto for a long time.
postmarketOS already got approval from Poettering to make a musl-linked systemd more officially supported.
I'd also add, that there are some non-trivial requirements for good server daemon programs, like fork, detach from terminal, may be fork again, umask, chdir, may be close some descriptors, maintain PID file, output to syslog, drop privileges and so on. And a lot of those things are implemented in systemd, so basically you can just write very dumb server which will work properly under systemd. So some part of systemd have to be implemented in every server daemon program.
More information at https://news.ycombinator.com/item?id=2565780
1. Agglutination of shell scripts
2. "Oh wow, this is getting annoying"-phase: Wrapper for scripts (SRC SMC openrc etc pp)
3. Service supervision daemons (SMF, launchd, systemd)
> Why didn't you just add this to Upstart, why did you invent something new?
> Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise.
> If you love Apple launchd so much, why not adopt that?
> launchd is a great invention, but I am not convinced that it would fit well into Linux, nor that it is suitable for a system like Linux with its immense scalability and flexibility to numerous purposes and uses.
launchd is horrible though, the folks complaining about systemd would be up in arms if they had to write poorly typed XML key/value files