>>9 no soy >>8, hice la pregunta en >>6, y no estoy conforme que se trate de vendor lock-in ni una estrategia a lo Microsoft de adoptar, extender y extinguir. Lo que más he leído por parte de los detractores va más por un modelo de funcionamiento más filosófico, en particular la filosofía UNIX de una función, un programa. Esto se sabe que no siempre es escalable, de hecho el núcleo del sistema operativo con su arquitectura monolítica y no de micronúcleo no ha tenido mayores quejas y las alternativas no han fraguado como en el modelo usado por Linux.

Otro asunto que se critica de systemd es que está inflado, pero ese inflado no es tanto por systemd. De hecho, hay aspectos del núcleo Linux, que es donde está la parte bien inflada de características que no se aprovechan y que no están en otros sistemas estilo UNIX y que para aprovecharlas era terreno inexplorado donde podría convenir un diseño particular más que otro al ir más allá de normas POSIX y sacar más provecho a lo que permite el núcleo.

Además systemd es relativamente modular: si no quieres usar journal, no lo uses, puedes usar rsyslogd o similar. Incluso es posible utilizar rsyslogd como entrada o salida (imjournal/omjournal) y que trabajen juntos. La ventaja agregada del journal es que se trata de información estructurada y almacenada de manera más eficiente, que también lo es para consultarla. Si tienes gran cantidad de logs es más rápido consultar por proceso, fecha y tipo de evento, resultando más conveniente que desde rsyslogd.

Es importante señalar que cuando apareció rsyslogd también había crítica sobre sus características y que apareciera en distros, muy inflada para casos de uso de máquinas modestas que no necesitaban combinar logs remotos de máquinas remotas o las opciones de cifrado para proteger la integridad y confidencialidad de la información, pero esto es de uso muy común, recordando que estos sistemas se usan incluso más en servidores que en computadoras personales. Hay montones de cosas que no necesitas en un sistema UNIX que lo hacen pesado y lento al arrancar, al igual que en Windows hoy en día. Irónicamente, journald es como el sistema de eventos de Windows y nadie va a dejar de usar Windows por ese hecho.

No se puede extinguir algo que es software libre. Los BSD siguen y seguirán existiendo, del mismo modo que macOS no extinguió los BSD por extenderlos aun con mucho código cerrado que las licencias no recíprocas de BSD permiten explícitamente apropiarse del código sin compartir el modificado. systemd tiene en la medida de lo posible una capa de compatibilidad POSIX, al igual que macOS, para mantener la interoperabilidad. Ha hecho más daño zsh y bash en mi opinión en romper características y vicios en los scripts de shell y nadie se ha llevado las manos a la cabeza con los "bashismos" por adoptar y extender, ya que extinguir a sh, csh y dash no parece haber logrado. Fragmentan más las distros con su sistema de paquetería sin querer ponerse de acuerdo con Linux Standard Base y gracias a ello ahora tenemos engendros cono snap o flatpak para no tener que empaquetar tarballs de slackware, (r)pm, deb, ebuild, pkginfo, nix, entre otros. (básicamente la problemática que menciona >>14).

Aquí existe libertad de elección. Si prefieres usar una distro que no aprovecha las características del kernel y que no tiene mucha alternativa, puedes. Pero no parece que sea tendencia o que tenga un rendimiento conjunto aceptable por otros factores, por ejemplo la comunicación entre procesos es menos eficiente para ciertos casos de uso que funcionan mejor con un sistema que orqueste mejor los servicios del núcleo en espacio de usuario que un montón de UDS (.sock) dispersos por el sistema o algo monstruoso basado en kdbus o aún peor, d-bus tradicional.

systemd lo utilizo para no tener que utilizar demonios cron y configurarlos de forma mucho más granular y aleatoria, no tener que pelearme en decisiones con los rc, mayores facilidades y muchas más prestaciones en el manejo de jaulas gracias a características del núcleo, aislamiento de procesos y configuración de los mismos de forma declarativa con el sistema de unidades, que permiten limitar muchísimos aspectos gracias a los grupos de control versión 2, incluyendo características propias de cortafuegos y sin usar reglas de cortafuegos, límite de consumo de recursos, etc. y de forma más eficiente y sencilla que con una maraña de scripts lentos que tendrían que ir consultando datos de /sys y /proc y con gran propensión a equivocarse en el código no declarativo.