It’s also really limited. I do a lot of shell programming and I lean heavily on Bashisms to get any work done. Even in Bash I’m hitting the wall constantly. Sh-only is utterly impractical: Reading code from big projects that try to stay compatible (e.g. automake) really show-cases these limitations. For instance, performing proper argument quoting of variables without arrays is next to impossible.

Even POSIX sh gives you effectively gives you a stack of lists in $@, one for each function call. If you absolutely must, you can maintain proper quoting very far with those. Shell is not as limited as you think, though it can be rather inefficient about it and it's probably not a good choice for programs whose designs it isn't especially good at handling.

For whatever reason, programmers tend to be rather dismissive of non-general-purpose programming languages, or more generally languages that do not work like conventional general-purpose languages, and refuse to learn them. I think the worst case we see of this is with CSS, where people come up with elaborate ways to place boxes procedurally in javascript (and JS once suffered from being considered a toy language, too), but I've seen similar attitudes get pointed at things like apache configuration, systemd unit files, jq, and Lua.

(On the other end, sometimes people believe that they're just writing configuration, and that this is somehow more maintainable than writing code, when really they're writing code embedded in a data description language; see Chef, Ansible &c.)

As for autotools, autoconf's "Portable Shell Programming" document covers seriously ancient shells. New programs following those guidelines aren't trying to stay compatible: their code isn't going to compile on the relics that run those shells without active effort that generally isn't happening. It's just a cargo cult.

I intentionally use it as a sanity check; if the task exceeds POSIX sh, it's time to pull out Python (for me; substitute your "real" language of choice).

This is a good heuristic for advanced logic, but not when the main purpose of the script is to encode a workflow of coding other tools. I’m using other languages for that too, but shell scripting languages are consistently superior to all of them (including Perl and Ruby, IMHO; workflow languages might help but pull in tons of dependencies).