I‘d say one of the primary reasons is compatibility. There is a lot of software for the Unix world that expects some kind of environment that behaves similarly to bash - imagine for instance of the bazillion of startup scripts that exist around certain tools. You’d have to be 100% backwards compatible with the bash language if you were to invent something to replace it, otherwise all those things wouldn’t work in your shell.

I still depend on so many Bash scripts.

I guess a mixture of POSIX compatibility, backward compatibility and non-interactive shell use-cases.

Being somewhat POSIX compatible offers a way to write scripts that work on many systems independent of the actual shell implementation (bash, dash, zsh…). But this means major overhauls of the shell “language” are out of question…

Backward compatibility gets important for things that ignored the first point and used features only available in bash. Given that bash is the default for 30 years for linux now there are probably plenty of examples.

And while bash is not the smallest shell it is also not the largest one…and rather configurable at compile-time when it comes to supported features. This makes it a viable option as “shell-script” interpreter for systems that hardly have any interactive shell usage. It’s not a completely bare-bone shell so you get a bit of “comfort” for scripts but you can remove unnecessary things like interactive command line editing with lib readline…I can imagine some embedded systems find uses for such a shell.

And it’s not that there aren’t alternatives…Microsoft’s Powershell is probably the most successful one “recently”. But changing all existing “workflows” from a text-based one to an object based one is not a trivial task…and in addition you run in new problems with any new shell design (For example I really dislike the overly verbose interactive useage of powershell but that’s rather subjective)

Why fix what isn’t broken?

The other answers are great. But consider the following, as well.

All the mainstream package managers rely on POSIX-ish shell interpreters. Arch Linux PKGBUILD files require bash syntax, specifically.

RPM and .deb package formats literally embed shell scripts to perform pre- and post-installation tasks. They treat these scripts like hooks.

For instance, a common task would be to create requires users and directories for a program. Quite literally something like mkdir -p /var/lib/myprogram.

Aiwendil has a good answer but I’d just like to add this nitpick (also @kromonos@fapsi.be ): bash and fish aren’t terminals, they’re shells