"1. Параллельный запуск демонов хоть и даёт небольшой прирост в скорости загрузки, разобраться, коль что-то пойдёт не так: тут даже логи не всегда помогут, требуется уже что-то вроде бутчарта и аналогичного функционала на завершение работы. Иначе хрен там разберёшься, какой демон или железка виноваты."
Тут нужно логическое мышление и умение пользоваться данной системой, если это всё есть, то нет ничего сложного.
И смысл не в параллельном запуске, а в полном контроле над ситуацией, который выполняет systemd, например, если будет запущен процесс, которые порождает другие процессы форканьем, то при закрытии данного процесса-родителя, должны закрыться все его дочерние процессы, но при форканье родитель теряется и дочерние процессы ему больше не принадлежат и поэтому они не закрываются. В systemd же родитель никогда не потеряется.
Также теоретически параллельный запуск даёт больше прибавки в скорости на быстрых носителях, например SSD и чем меньше носитель тормозит загрузку, тем больше выгода, а на жёстких дисках его будет тормозить параллельное считываение информации с медленного жёсткого диска, поэтому считай, что в данном случае в системд всё равно всё грузиться последовательно, именно из-за скорости жёсткого диска.

"2. Функционал далеко за рамками необходимого для системы инициализации с сопутствующим вытеснением различных утилит элементами системд. Т.е. у пользователя отбирают возможность выбора: или используй всё от Поттеринга, или дистрибутив не для тебя."

Ну во первых - это уже не система инициализации, а базовый набор необходимых утилит.
А во вторых ничего не отбирают, там есть выбор - если какие-то модули не нужны, то не компилируйте их, можно вообще использовать только базовый минимальный набор.
systemd - она модульная и можно заменять модули на свои.
systemd - это не один бинарный файл, а их там полно, каждый из которых выполняет свою функцию и большинство из них можно без труда заменить на свои аналоги.

"4. Конфигурация по сути чёрный ящик. Для простых случаев накатать юнит просто, а вот для чуть более сложных — придётся лезть уже в код системд, где не вот и разберёшься ещё."

Нахрен лезть в код systemd ?
Для большинства задач подойдут юниты, именно поэтому они и появились, т.к. они удобней скриптов, занимают меньше места, легко читаемы и быстрей работают, т.к. основной код заключён в systemd и написан на Си, а юнит - это файл настроек, но если вам юнита не хватает, то напишите скрипт - systemd именно для этого их и поддерживает.

"3. Спорные (мягко говоря) решения вроде бинарных логов."
По-моему всё понятно. Обычные текстовые файлы содержали бы кучу повторяющейся информации, а бинарники компактней и плюс сама systemd выдаёт больше информации, чем другие системы. Но если вас, как разработчика дистрибутива это не устраивает, то залезьте в исходники и подпишите там запись в текстовой файл - это сделать не сложно.
Ещё я подозреваю, что логи бинарные потому, что они скорее всего устроены внутри, как база данных, но тут не знаю.