Уважаемый, эта тема не раз уже была затёрта до дыр.

Грубо говоря, есть проблема несокращаемой сложности.
То есть для полноценной инициализации демона вам нужно проделать такие-то и такие-то приседания в такой-то и такой-то последовательности, а так же отловить и обработать все ошибки, которые могут в ходе этого процесса возникнуть.
Затем вам понадобится следить за этим демоном: уметь находить его запущенную копию и корректно убивать её.
(Современные реалии (дешёвая виртуализация в каждом колхозе) также таковы, что нужно полноценно следить за группами процессов: то есть если я запустил демон, и останавливаю его, в подавляющем большинстве случаев я имею в виду также останов всего, что он назапускал.)

Дык вот, всё это -- сложные вещи.  Если вы берёте очень простой init, то вся эта сложность оказывается на плечах клиентов этого init.  То есть по умолчанию каждый (программист или сопровождающий пакета или админ) лепит сложный, а зачастую очень сложный, скрипт инициализации.  Проблема эта хорошо известна много лет, из-за чего везде наизобретали велосипедов вокруг SYSV init: библиотеки shell-функций для скриптов, запускалки демонов типа дебиановской start-stop-daemon.  Это закономерно приводит к тому, что 99% скриптов инициализации используют очень простой инит и все эти дистрибутиво-специфичные велосипеды.
Получается простой инит со сложными скриптами.

Это ещё не всё.  Если Вы пробовали писать демон для системы, основанной на Linux, то Вы неизбежно приходили к мыслям типа "а какого хрена нужно отдельно приседать для отладочной работы без отсоединения от управляющего терминала и для работы в режиме демона?", "на кой хрен нужен двойной форк и setsid() в правильной последовательности?", "почему нужно писат разный код для протоколирования на stderr и в сислог?", "что делать, если демон упал из-за внутренней ошибки?" и т.п.  Ясно, что этими вопросами задавались многие умные люди, и потому появились runit, daemontools, хелпер daemon и прочие.  А также отдельные узконаправленные решения для хостинга, например, HTTP-демонов, написанных на питоне.

А ещё попробуйте сами сделать активацию по сокетам?  Говорите, "использовать inetd"?  А как быть с зависимостями?

А легковесные контейнеры (да, XXI век уже здесь)?  Напишем для них отдельный инит?

В итоге:

* Поскольку есть несокращаемая сложность, нужно где-то провести линию между инитом и его клиентами.  В systemd эту линию провели ближе к иниту, чем в SYSV init.
* Systemd позволяет делать простые вещи просто, а сложные -- при необходимости -- всё же делать; не сложнее, чем раньше.
* Он позволяет делать демоны проще и логичнее.  В частности, их можно легко писать на чём-нибудь, отличном от Си, без специальных приседаний.
* Он умеет всё или почти всё из того, что делают спец. приблуды вроде runit.
* Он умеет помогать легковесной виртуализации.

TL;DR

Можно написать инит ещё проще, чем SYSV init (посмотрите, например, на ss6), но тогда скрипты инициализации и жизнь разработчиков станет ещё сложнее.