z. B. fish gar nicht erwähnt habe.

Ja. Fish kenne ich auch. Finde ich eigentlich auch gar nicht so schlecht. Bietet nette Funktionen und ist auch vom Start weg sehr gut benutzbar ohne das man irgendwas konfigurieren muss.
Man hat sozusagen schon was davon, indem man sie einfach nur installiert.
Mir geht sie aber in manchen Dingen einfach nicht weit genug und macht Dinge anders als ich sie mir wünschen würde.
Dennoch ist es eine sehr empfehlenswerte Shell für Leute die da mal was anderes abseits von Bash probieren wollen.

Das heißt, es gibt neben dem explizit definierten Standard für die Kommandozeilensprache unter Unix auch noch eine Art De-facto-Standard an Erweiterungen. Und das ist, bei aller berechtigten Kritik an der idiosynkratischen Syntax und der Mangelhaftigkeit der Shell-Sprache, eine ziemlich komfortable Situation, denn die Unix-Kommandozeile kommt damit faktisch einer universellen Benutzerschnittstelle relativ nah.

Ich sag ja auch nicht, das andere Shells dafür verschwinden sollen. Aber als Ergänzung? warum nicht?

Kann man ja so ein bisschen vielleichen mit dem vi. Den gibts auch "überall". Wenn Du also irgendwie unter nem "UNIX" ne Datei editieren willst, kannst Du sicher sein nen vi zu haben. Es ist praktisch, wenn man den zumindest halbwegs beherrscht.
Trotzdem würde ich nicht auf die Idee kommen ihn deshalb ständig einzusetzen.

Warum sollte ich das bei einer Shell nicht machen? Ich muss ja nicht mal meine Standardshell ändern. Ich kann ja meine Lieblingsshell jederzeit aufrufen, wenn ich meine ich möchte sie in dem Augenblick nutzen.

Hinzu kommt, dass, im Gegensatz zu grafischen Desktop-Umgebungen, der Kommandozeileninterpreter offenbar viel eher in Aufgabenbereichen eingesetzt wird, in denen es wirklich drauf ankommt, dass Dinge stabil laufen. Die Shell ist schlicht das klassische Werkzeug von (professionellen) Systemadministratoren, deren Arbeitsbereich sich üblicherweise eher schlecht für Experimente eignen dürfte.

Genau dann ist aber die Shell eher wacklig. Gerade wenn Du Scripting-Sachen machst. Es gibt einfach so viele Stolperfallen. Klar kann man die umgehen. Aber besser ist natürlich, wenn es die gar nicht erst gibt.

Und sind Skripte einmal in Bash oder KornShell geschrieben und wurden womöglich über Jahre hinweg vorsichtig verbessert, wird da sicherlich (und verständlicherweise) wenig Bereitschaft bestehen, daran grundlegend etwas zu ändern.

Hat ja auch niemand behauptet, das bestehende Skripte alle neu geschrieben werden sollen.

Aber wo wir gerade beim Scripting sind:
Ne Shell erfüllt ja i.d.R. heutzutage zwei Aufgaben. Erstens das schon angesprochene Scripting, zweitens eine interaktive Benutzerstelle. Mal abgesehen davon, das es gegen "one Job one tool" verstößt ist es auch so, das es beides nicht optimal erfüllt und vielleicht auch nicht erfüllen kann.
Nicht umsonst gibt es ja immer mal wieder Bestrebungen den Scripting-Teil mit was anderem zu machen. Perl ist ja da das klassische Beispiel für. Die reellen Geschehnisse zeigen also schon, das es da eine gewisse Spannung in der Thematik gibt.

Fürs Bereich Skripting hat sich da ne Menge getan. Sei es nun Perl, Python, Ruby oder was auch immer, da gibt es reichlich Optionen die den Teil angehen und Alternativen bieten. POSIX-Shell-Scripte oder von mir aus auch noch Bash-Skripte haben natürlich weiterhin den Charme, das sie überall ohne großarige Voraussetzungen laufen. Aber damit hat es sich auch schon an Vorteilen.
Auf der Seite der Interaktion mit dem Nutzer hast Du das meines Erachtens nach weniger Bewegung drin. Es gibt sie, aber die sind eben (wie schon gesagt) nicht so präsent.

Wie gesagt. Es schätze es auch, wenn es einen Minimalstandard gibt der überall funktioniert. Für den täglichen Gebrauch wäre mir das aber dann doch zu rudimentär und unkomfortabel.