This is the first anti-systemd article that I've read that focuses exclusively on the technical issues with it (well, mostly: the last one kind of gets touchy on the politics). And this article is a good summarization of them.
Linux in the server world is rapidly turning into a thin platform hosting containers (docker, kubernetes, etc) of "fat" Linux distros. Systemd makes a lot more sense if you consider it in that context: a container can use systemd to have the host start a monitoring process whenever any processes are executed, etc. Sure, this probably could have been grafted on to sysvinit, but it would have been an ugly hack just like every other thing that's been grafted on to sysvinit.
Linux everywhere else but the server world is all about low power usage and tight integration with custom hardware. Embedded devices, mobile phones, tablets, wearables, etc. All of these use cases demand an init system that is aware of and able to manage the system power state as a gradient, not a binary value. Again, this could probably be hacked on to sysvinit or the kernel itself, but would require big kernel changes and likely a fork for "Mobile Linux" and "Server Linux" as the market begins to demand power-aware schedulers, memory mappers, etc.
If the computing world were to remain in a paradigm where we run small physical or virtual servers dedicated to tasks, then sysvinit would be fine. But that's not where we are today nor where we will be, and sysvinit simply isn't flexible enough for a lot of the use cases where Linux is seen today. The *BSDs exist if you want a rock-solid and simple x86 Unix system for hosting traditional applications in a client-server setup; but if you want a flexible platform for building arbitrary products, Linux is the way to go.
Linux in the server world is rapidly turning into a thin platform hosting containers (docker, kubernetes, etc) of "fat" Linux distros. Systemd makes a lot more sense if you consider it in that context: a container can use systemd to have the host start a monitoring process whenever any processes are executed, etc. Sure, this probably could have been grafted on to sysvinit, but it would have been an ugly hack just like every other thing that's been grafted on to sysvinit.
Linux everywhere else but the server world is all about low power usage and tight integration with custom hardware. Embedded devices, mobile phones, tablets, wearables, etc. All of these use cases demand an init system that is aware of and able to manage the system power state as a gradient, not a binary value. Again, this could probably be hacked on to sysvinit or the kernel itself, but would require big kernel changes and likely a fork for "Mobile Linux" and "Server Linux" as the market begins to demand power-aware schedulers, memory mappers, etc.
If the computing world were to remain in a paradigm where we run small physical or virtual servers dedicated to tasks, then sysvinit would be fine. But that's not where we are today nor where we will be, and sysvinit simply isn't flexible enough for a lot of the use cases where Linux is seen today. The *BSDs exist if you want a rock-solid and simple x86 Unix system for hosting traditional applications in a client-server setup; but if you want a flexible platform for building arbitrary products, Linux is the way to go.