Da ich beruflich mit Linux zu tun habe und mich mit der Thematik befasst habe, finde ich den Artikel nicht so gut und ich finde, dass er ein (zumindest in Teilen) falsches Bild vermittelt. Ich wiederhole hier zwar ein paar Dinge die vor mir schon gepostet wurden, das stört mich aber nicht
Das beginnt recht weit oben, wo nur auf MBR, nicht jedoch das bei modernen Systemen eingesetzte GPT eingegangen wird. Gravierender: Grub zeigt basierend auf seiner Konfiguration einen Auswahlbildschirm und (entpackt und) startet dannach den ausgewählten Kernel, der dann optional seine initrd entpackt und ausführt. Der Artikel springt vom Kernel wieder in Grub zurück, was schlicht falsch ist.
Grub selbst übergibt auch nichts an das init-system, allenfalls eine Direktive an den zu startenden Kernel, der diesem explizit ein bestimmtes Programm als als erstes zu startendes vorgibt (init=/bin/bash für eine Rescue-Shell, init=/sbin/init für das normale init-system).
Runlevel sind nicht universell durchnummeriert. Init-systeme wie OpenRC (ich verwende das gerne für meine Debian-Rechner) haben benamte Runlevel wie "boot", "default" oder "shutdown", das ist aber an dieser Stelle nicht so wichtig.
Auch wenn SysV Init nicht parallel Dienste starten kann, so gibt es auch hier Alternativen die das können. Bei OpenRC (als SysV Init Aufsatz) ist das zwar als experimentell markiert, funktioniert aber sehr gut. Was mir sehr fehlt ist, dass es nicht zwingend am parallelen Starten von Diensten liegt, wie schnell ein System verfügbar ist. Die schiere Menge an Diensten die beim Start moderner Linux-Systeme hochgefahren werden ist erdrückend, vieles davon wird von den allermeisten nicht oder nur selten benötigt (und kann dann bei Bedarf bspw. über Abhängigkeiten gestartet werden).
Die Methode, alles was der Benutzer brauchen "könnte" zu starten führt dazu, dass sequentielle init-systeme ins Hintertreffen geraten, eine Reduktion der Dienste oder Starten derselben bei Bedarf ist jedoch auch mit den klassischen Systemen möglich. Selbst mit streng sequentiellem Starten kann man mit minimalen Eingriffen die Bootzeiten eines alten Core 2 Duo-Laptops von Start des Kernels (also Auswahl eines Eintrags in Grub) bis zum Anmeldebildschirm von bspw. KDE auf einstellige Sekundenwerte kommen. Dienste on-demand starten ist kein Hexenwerk, es macht sich mW. nur keiner die Mühe dass mal umzusetzen, sodass beispielsweise CUPS erst startet wenn man den ersten Drucken-Dialog aufmacht.
DBus-Nachrichten werden nicht vom Kernel gepuffert (zumindest bis KDBUS es in den Kernel schafft), sondern allenfalls vom DBus-Daemon der als normaler Dienst auf dem Rechner läuft. Was mir hier auch fehlt: klassische init-systeme nutzen den DBus im allgemeinen wenig bis garnicht, im Artikel wird nicht explizit zwischen systemd und SysV Init unterschieden.
Ein frühes starten des syslog-daemons kann man auch anders als mit systemd erreichen. Alternativ können init-systeme wie OpenRC bei Bedarf selbst logs schreiben. Wenn mein System beim Booten hängen bleibt und ich es nicht mehr starten kann, kann ich auch erstmal keine syslog-Meldungen ausgeben lassen, das ist universell bei allen Systemen so und hier kann systemd auch nichts an den Tatsachen ändern. Die binären Logfiles von systemd gereichen denn auch zum Nachteil, wenn ich ein minimalistisches System habe, oder gar von windows (bei ext bspw) auf die Partitionen zugreife: ich kann die Dateien nicht öffnen. Dazu kommt dass sie aufgrund der binären Struktur anfälliger für Korruption bei diversen Fehlerfällen sind.
Das Starten der Dienste muss nach dem Einhängen der Partitionen passieren, gerade systemd benötigt eine gemountete /usr-Partition _bevor_ es selbst starten kann. Viele Dienste benötigen sowieso Daten aus allen Teilen des Systems und deswegen werden die Partitionen auch entsprechend früh eingehängt.
Super und weiter so! 
