5. Tabs benötigen deutlich weniger Tastendrücke beim Verwenden und Entfernen!

Das stimmt nur so halb. Beim Setzen stimmt es gar nicht (Editoren füllen bei entsprechender Einstellung mit Spaces auf), beim Entfernen ist es richtig, dass nicht alle Editoren, die ich so kenne, beim Druck von Backspace „eine Einrücktiefe“ an Spaces entfernen, aber einerseits machen das etliche Editoren durchaus und andererseits ist das meiner Einschätzung nach kein wahnsinnig relevanter Use-Case, weil Shift-Tab die korrekte Tastenkombination für den Einsatzzweck ist.

Anders gesagt: Editoren abstrahieren den „Unterschied“ zwischen Tabs und Spaces weg. Ich erkenne es an, dass man das dennoch als Argument für Tabs auffassen kann, weil die Tab-Taste für Spaces gewissermaßen „zweckentfremdet“ wird, aber im Gebrauch funktioniert das schlicht und ergreifend problemlos und wunderbar. Der Vorteil (aus Sicht von Spaces-Nutzern) ist eben, dass die Ambiguität der Tab-Weite aus der Gleichung rausgenommen wird.

Mein Argument hier ist, dass es in der Anzahl der Tastendrücke (-drucke?) nicht den geringsten Unterschied gibt, ob Tabs oder Spaces genutzt werden.

Letztlich ist der Punkt bei dem Thema meines Erachtens immer, ob man es aushalten kann, eine fest definierte Einrücktiefe (gemessen in Spaces) zu nutzen. Und ich bin der Ansicht, dass man das kann, weil man eben x andere Aspekte an der Formatierung des Quellcodes auch nicht durch Nutzung bestimmter Kontrollzeichen beeinflussen kann, weil diese Kontrollzeichen schlicht und ergreifend nicht existieren. Dass das mit Tabs „geht“, ist meines Erachtens eher ein Zufall oder ein Nebeneffekt der ursprünglichen Bedeutung der Tabulator-Taste.