What it is mostly used for are file system operations. Guess what it is bad at? Operating on files. It automatically splits and carries out filename expansion on every single string resulting from variable expansion and command substitution unless quoted, by default on whitespace, whilst spaces are very common in filenames.

Before that, it even does pathname expansion, so woe to anywone who does not want to actually operate on files, but has a globbing metacharacter stored anywhere in a variable.

This means what you store in a variable is not going to be what will ACTUALLY be accessed.

If an empty variable is unquoted, it disappears completely due to word splitting, sometimes leading to applications signalling a missing parameter at a wrong position.

If quoted however, said variables cannot be iterated over in a loop, no matter what character one uses for word splitting.

If you use any globbing pattern with a command, be sure to use -- after the option arguments or if none are present, before starting the pattern with a mandatory ./

Otherwise, another Bash script run gone wrong or a hacker can create files named like an option ("-f", for instance) and your program will happily accept it as such, if it results from globbing.

For interactive use, it is convenient. For programming, it is a no-go.

In Bash, exceptions are the rule, not even all being described by the main page.

There are a grand total of 5 different ways of quoting, sometimes even when one does not want to, for instance in command substitutions. These are all based around preserving the literal meaning of every character, with an exception list. There is even an exception list to the exception list in 4 of the 5, regarding how the backslash behaves! The behavior of the backslash is also one of the quoting rules, so naturally, it also has an exception in how it works when it stands before a newline as compared to other characters.

Bash has several layers of interpretations, all to be kept in mind:

The ~ expands to the home of the current user. So if you store it in a variable, can you use it that way? Nope: tilde expansion comes before variable expansion.

Aha, so that's how it works! Then, since applying quotation happens after redirections are set up, it must mean that redirecting within quotes works, right? Nope: there is an exception! If a redirection symbol is not quoted, quotation around the symbol is observed, but is not removed. So, since variable expansion also comes after setting up redirections, and no exceptions are described here in the man page, getting the name of a file from a variable and using it as a target should not work, right? No: redirection does not actually take place when the symbols are being read, the symbols are merely removed and are noted for later, right before when the actual command runs.

Apart from 5 types of quotation, there are basically 2 quoting phases, 2 word splitting phases (with only one being controllable), and a tokenization phase on top of that.

If you have a command, it could be an alias, a special built in, a non-special built in, a symbolic link to a file, a regular file, a function, with different rules regarding how they can be overridden, if redirection happens before or after arguments have been passed (what does "time my_command 2>&1 >log_file" do?), etc.

This list is admittedly long, but it doesn't even scratch the surface of the bloat, complexity and inconsistencies of Bash.

People who wants power features or to customize their shell experience use zsh or fish.