A lot of the time you don't even have the luxury of assuming "bash" is present, you've got only "sh".

Since all valid "sh" syntax is valid "bash", you've got to restrict yourself to only sh-valid code in the event the host doesn't have bash.

I have gotten used to doing this -- these scripts usually wind up being run in Docker containers that don't have "bash" installed for the sake of minimalism.

IE, you can't use [[ $predicate ]], but instead [ $predicate ], etc. Lot of subtle differences.

Not all sh syntax is valid bash — in bash [[ is reserved but not in sh. And if you want syntax that is valid but doesn’t do the same thing in sh vs bash there’s plenty of examples.

You can't ever assume that /bin/sh is a POSIX shell so then you get limited to just an early Bourne subset.

I would agree with this and use python instead, but for uuhh "python problems with strings". IF you are 'blue sky' open, making new things, yes, sure. no BASH. But for things I built 8 years ago that are non-trivial, and I don't prioritize an entire rewrite, BASH works very well. And guess what, every two years that 8-years-ago just comes along with it. BASH is here to stay.

The POSIX shell can sometimes achieve with a few lines what would take dissertations to do in C.

The supersets of POSIX are often even more effective.

Ugly as the tool may be, in the box it stays.