Реализовать systemd без systemd можно, но едва ли осмысленно. Тем более делать это каждый раз под каждый отдельный шеллскрипт - и того затратней. И главная фича системд вовсе не паралельный запуск, логи или вотчдоги, а возможность реагировать на любой системный ивент - udev-dbus-evdev и адаптировать систему к новому железу, новым условиям и новым состояниям на лету, через единый декларативный интерфейс.
В 80-ые может и можно было запустить демон и забыть, да расчитывать что он не сдохнет, да inetd какой вытянет то мизерное число коннекшенов, что приходило на сервера до середины-конца 90-х, но после нулевых, с приходом хайлоада во все дома - это уже едва ли вариант. Во-первых сервис надо не только запустить, но и быть уверенным, что он всё ещё работает, помогать ему если он вдруг не-. Сервис так же надо переконфигурировать по мере обновлений конфигов, наплыва памяти или хотплага девайсов. Последнее особенно актуально в десктопных конфигурациях, между прочим, там источником события могут быть и действия юзера. Так же, возвращаясь к тем же серверным конфигурациям нужно не беспокоится что форкающийся динозавр выжрет все сокеты, всю память, наплодит зомбей и уйдёт в oom, нужен адекватный ресурс-менеджемент, что системд в числе прочего и предоставляет, наряду с управлением слайсами и ядерными контейнерами.
Минималистичность - это конечно здорово, но только пока не требуется на каждом шагу заново интегрировать три-четыре независимых решения для разных задач, чтобы они могли работать в тандеме, а не каждая в свою сторону, тем более в рамках изолированых кустарных скриптов. Да и никто не отбирает у минималистов опции сделать всё как сами считают нужным, пока другие человеки могут делать что-то полезное, не отвлекаясь на реализацию одной задачи в тридесятый раз.