Trotzdem bin ich nicht damit einverstanden, dass diese eierlegende Wollmilchsau sich nach und nach im gesamten System ausbreitet.

Ich kann diese Haltung nachvollziehen, allerdings muss ich an dieser Stelle sagen, dass systemd-journald zuvor in Debian ohnehin schon parallel zu rsyslogd lief. Diese Entscheidung würde nicht zu einer erweiternden Ausbreitung systemds führen.

Habt eigentlich irgendjemand einmal über das einfache Grundprinzip nachgedacht, das ein System (insbesondere ein Programm) mit zunehmender Komplexität immer anfälliger für Fehler (und damit auch für Angriffe) wird.

Da haben sicherlich schon viele darüber nachgedacht. Offenbar werden seitens der Entwickler einige Funktionen von systemd benötigt. Vom Konzept her ist es ja auch nichts neues. Lennart hat sich von launchd und SMF inspirieren lassen. Also scheinen zuvor schon andere namhafte Plattformentwickler die Wichtigkeit dieser Funktionen eingesehen zu haben. Und die Funktionen werden teils rege genutzt. In vielen Fällen auch aus gutem Grund und in Ermangelung an funkionellen Alternativen.

Nicht in jedem Anwendungsfall sind diese Funktionen nötig. In einige Szenarien kommt man SysVinit gut aus. Allerdings hat sich das Aufgaben- und Anforderungsfeld über die Jahrzente derart geändert, dass sich einige Dinge nicht mehr sauber auf die Konzepte von SysVinit abbilden lassen. Es mussten neuartige Konzepte her, die die bisherigen Anwendungsfälle so gut es geht unterstützen oder abbilden.

Natürlich bedarf dies einer höheren Komplexität innerhalb systemds. Andernfalls wäre SysVinit nicht gescheit implementiert gewesen. Offenbar waren aber die Vorteile, nämlich die Minimierung der Schwierigkeiten in den darüberliegenden Schichten derart enorm, dass dies die Nachteile wett macht(e). Ein Vorteil ist auch, dass die Distributoren nun viel stärker kollaborieren als zuvor, denn vor systemd hat jeder sein eigenes Ding gedreht. Das frisst auch unnötige Entwicklerressourcen - nicht nur an init selbst, sondern eben auch in den darüberliegenden Schichten, wegen unnötiger Fragmentierung.

Meiner bescheidenen Meinung nach ist der einzige Grund, warum ein gewisser Debian-Entwickler den 'rsyslog' ab liebsten wegwerfen würde, ist der, dass er sich weniger Arbeit machen möchte ... was ja noch irgendwo einzusehen ist. Wenn allerdings der 'rsyslog' von diesem Entwickler nun gar nicht direkt betreut wird, dann [...]

Das systemd-journald wurde seit systemd in Debian Standard ist, standardmäßig betrieben, wie es für alle mir bekannten systemd-Distributionen üblich (oder sogar nötig?) ist. Nicht nur in Debian wurde für die Wahrung der Kompatibilität weiterhin rsyslogd nebenher betrieben, systemd-journald leitete die Logs nur weiter. Für diese Aufgabe war systemd-journald u.A konzipiert. Weitere Gründe waren meinen Vermutungen nach einerseits, dass systemd-journald noch nicht die gewünschte Reife hatte bzw. zentrale Features noch fehlten, und andererseits ein Art "Salamitaktik" bei der Einführung in Debian. Die Binärlogs waren (und sind teils noch) sehr großte Kritikpunkte. Die Handhabung etwaiger Korruptionen der Logs wurde verbessert.

Ergo liefen (und laufen noch) die ganze Zeit zwei Log-Dienste parallel, was unsinnig ist. Wenn jetzt systemd-journald in Debian Standard wird, heißt das eigentlich nur, dass eine Einstellung umgebogen wird und rsyslogd (eventuell, ist noch in Planung/Verhandlung) optional statt essentiell wird, womit rsyslogd standardmäßig nicht mehr installiert würde, aber nach einer Installation so läuft wie zuvor auch. Und das wird langfristig auch so bleiben. Ich sehe keinen guten Grund, warum systemd-journald die Hoheit auf Logs beanspruchen sollte, rein technisch und politisch nicht. Das Risiko wäre viel zu groß.

systemd-journald wurde in Debian die ganze Zeit schon betrieben und musste daher auch entsprechend gepflegt werden. Es geht darum, dass sich das Projekt als Gesamtheit weniger Arbeit macht, und der Großteil der Installationen weniger Ballast mitschleppt und Ressourcen fürs doppelte Logging verschwendet.
Ihr Argument finde ich demnach äußerst schwach.

Na gut ... man muss ja 'rsyslog' nicht zwangsweise einsetzen. Für mich sieht das aber so aus, wie bei der Diskussion um das Init-System selbst, nämlich den Versuch, den 'rsyslog' vollständig aus dem System zu werfen [...]

Das glaube ich nicht. Die Befürworter von der Umstellung im Artikel geht es um den Regelfall. Sie nehmen wohlwollend zur Kenntnis, dass es sehr gute Gründe gibt, anderer Log-Dienste als systemd-journald einzusetzen.
Darüber hinaus haben sie allein nicht darüber zu entscheiden, ob oder wann rsyslogd aus Debian hinaus fliegt. Das liegt allein an den Maintainern und deren Pflege des Pakets. Ich kann nicht erkennen, dass es schwieriger werden sollte, rsyslogd unter Debian zum Laufen zu bringen. Das ist jetzt nicht wie ein udev oder logind, das zurechtgebogen werden müsste.
Außerdem ist SysVinit nach wie vor in Debian enthalten, siehe hier.

Auch diese Befürchtungen bzw. das damit aufgestellte Argument wäre damit entkräftet.