Что берёт ?
http://packages.altlinux.org/en/Sisyphus/srpms/systemd
$ rpm -qa | grep systemd
systemd-journal-gateway-201-alt1.M70T.1
libsystemd-login-201-alt1.M70T.1
systemd-201-alt1.M70T.1
libsystemd-journal-201-alt1.M70T.1
systemd-analyze-201-alt1.M70T.1
libsystemd-daemon-201-alt1.M70T.1
systemd-sysvinit-201-alt1.M70T.1
libsystemd-id128-201-alt1.M70T.1
Убираем из списка systemd-journal-gateway и systemd-analyze (это доп. функционал, не влияющий на работу системы инициализации, как таковой). В сухом остатке остаётся сам демон, присутствие которого необходимо для работы системы, вспомогательные утилиты, слой совместимости с sysv по части адаптации service и прочих утилит и журнал как отдельная сущность (в смысле отключаемая и заменяемая).
Как это мешает работе системы ?
Множество несвязанных точек отказа сводятся в одно место. То есть, это потенциальное место для ухудшения стабильности системы. Допустим, я не хочу обновлять сам init, мне это не надо. Но мне надо обновить udev, а там зависимость "Requires: udev = %epoch:%version-%release". Хочешь, не хочешь - потянется сам systemd. А, вдруг, там баг новый ? Ну на кой ляд мне новый init из-за нового udev ? Мне, случись что, через пол-города по пробкам к серверу мчаться ? Или KVM-переключатели с доступом по IP срочно теперь расставлять ?
1) Множество несвязанных и раскиданных по системе точек отказа (на которые обращают мало внимания в связи с возрастом) потенциально хуже диагностируется и дольше исправляется, чем проблемы в каком-либо одном компоненте (который без внимания не остаётся с самого момента своего появления)
2) Мы вроде бы договорились, что речь идёт о десктопных дистрибутивах (с серверами всё давно понятно - не зная броду, не суйся в воду, если брод известен, то можно использовать, но требуется предварительная настройка под свои нужды) и вот применительно к десктопам я пока не вижу ни одной реальной точки отказа в повседневном безжалостном использовании (в том числе и чайниками, малоподготовленными людьми) систем с программным обеспечением под названием система инициализации systemd (правда надо заметить, что это не говорит о том, что ошибок нет; они наверняка есть, но, видимо, не столь значимы для работы системы).
3) Хм, а как же образы тогда без systemd собираются (на этапе сборки дистрибутива все зависимости входящих в дистрибутив пакетов точно также обрабатываются, как и при обычной установке или удалении пакетов), ведь сам системд туда не попадает, а удев там есть ?