- It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong"
- Systemd is not just an init system, it's a message bus, authentication system, logging system, container management system, xinitd system, and any other number of highly coupled systems.
- Service startup order can still be non-deterministic and fairly slow; hard init problems have been made harder, while easy init problems "only" remain easy.
- Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically.
- Failures are opaque, and the failure of systemd triggers the failure of the entire system.
The original idea that drove systemd's creation is still fairly sound: create a simple, deterministic, and parallel init system which is better than initv. The implementation doesn't live up to those goals, and instead of iterating against that goal, the team's focus has shifted to take over all aspects of the Linux runtime which isn't managed by the kernel.