In many cases, the fact that it's far from trivial to figure out whether your script is portable or not, makes them not portable for practical intents and purposes. I would say that for most people and most use cases, shell scripts are write once and hope you never have to edit them again, and even knowing one way of comparing values may be problematic while another might not be is beyond the given pay grade.
You can of course test portability by testing, or simply writing, your script against a POSIX-only shell interpretation. It's a lot easier to change a shebang (#!/bin/ash -> #!/bin/sh) than to rewrite the full script during a firefight.
One might even suggest "/bin/bash considered harmful".
One also may suggest "/bin/sh considered harmful". Does the rest of the world have to suffer just because Solaris can't be arsed to upgrade its tooling (much of it is very tentatively POSIX-compliant anyhow) so they block any new additions to the /bin/sh features in the POSIX?
The dash shell compiles to 80k on an i386, which is viable for embedded applications.
The POSIX shell was standardized in view of the original Korn shell, which could compile to 64k on Xenix 286.
The functionality was reduced in an effort to increase code maintainability.
Edit:
"A lot of effort was made to keep ksh88 small. In fact the size you report on Solaris is without stripping the symbol table. The size that I am getting for ksh88i on Solaris is 160K and the size on NetBSD on intel is 135K.
"ksh88 was able to compile on machines that only allowed 64K text. There were many compromises to this approach. I gave up on size minimization with ksh93."
This can be said of most programming, in Java, C++, golang, Pascal and Ruby I have been on projects that could not compile. The dependencies are so out dated a complete rewrite is easier. I do not find bash worse or better. You just do alot more with less lines in it.
