It is even worse on MacOS, because Apple bundles the BSD versions of common Unix utilities instead of the (generally more featureful) GNU versions. So good luck writing a Bash script that works on both MacOS and Linux...
First thing anyone doing dev on MacOS should do is install brew. Second is use brew to install the coreutils and bash packages to get a linux-compatiable gnu environment.
Also because the vast majority of MacOS users never open a terminal. Unix utilities are something they don't even know they have, and they don't care what versions they are.
Anyone using MacOS as a unix platform is installing updated tooling with brew or similar.
MacOS userspace was forked from FreeBSD, that's why it bundles non-GNU extensions. Also the FreeBSD userspace has since then incorporated GNUisms.
Why they went with Bash 2 as the defualt shell is beyond me. I always switched to and used Zsh which had a more recent version. Now I'm also using it on Linux and FreeBSD, because I want a consistent shell.
The macOS userspace was never forked from FreeBSD or any other BSD. If anything, it was forked from NextSTEP. In actual practice, it is a collection of individual components taken from a variety of sources. When development of Mac OS X began in 1999, most command-line tools and a large part of libc were derived from either NetBSD or OpenBSD via NextSTEP. Over the years, there has been a shift toward FreeBSD. Apple maintain a collection of GitHub repositories of their Open Source components where you can see the evolution from one release to the next. Most of them have XML metadata indicating the origin of each individual component.
Incorrect. They default to zsh for interactive use, but their /bin/sh is bash 2. They also ship a copy of dash, but it's not sufficiently POSIX-conforming to replace bash.
Huh weird, I remember many years ago getting a notification in the terminal that bash would be deprecated so I assumed that would have happened by now. I no longer use macs so I wasn't up to date, sorry.
As an OpenBSD developer who frequently fixes portability issues in external software, this doesn’t match my experience. Upstream developers are typically happy to merge patches to improve POSIX compliance; often the result is simpler than their existing kludges attempting to support desired platforms like MacOS, Alpine/Musl, Android, Dash-as-sh, and various BSDs. It turns out a lot of people find value in relying on an agreed‐upon behavior that’s explicitly documented, rather than “this seems to work at the moment on the two or three distros I’ve tested.”