The main difference - as I understand it - is that the BSD variants are strictly POSIX compliant, while GNU tools decided to diverge from that behavior (see: POSIXLY_CORRECT, other compatibility flags) for better usability, more features, and so on.
So, if anything, it is GNU that is "different" and "incompatible".
(Not necessarily a bad thing, mind you)
What I mean under "incompatible" is not-supporting everything that the other does. Just couple of trivial examples: `sed -i 's/require/include/' Rakefile` throws `invalid command code R` Mac (you must use `sed -i "" 's/require/include/' Rakefile` instead) and `dd` does not support `status=progress` on Mac so you have to pipe it through `pv` and this is not free in terms of performance.
If that doesn't work, do stty status ^t first.
This is SIGINFO; it's been in BSD for a long time, but isn't in Linux and is relatively unknown nowadays. Quite a few BSD command line programs will respond to it.
I would argue it’s the GNU tools that are not 100% compatible. The BSD tools are very much the same as they always have been in Unix of old.
GNU was in fact doing what we generally refer to as „embrace and extend“. And now look at how well it has worked: people refer to the original as „not compatible“
Of course it’s not so relevant as the gnu tools are widely available, but it’s in my opinion still an observation of note.
Of course, that's the point: the GNU tools undergo relatively active development and grow better while the BSD tools don't.
In some GNU tools we are even required to explicitly enable POSIX compatible behavior.
However I do agree that GNU tools are easier to use.
Back in the .com days, when I did SunOS administration, they would be one of the first external packages I would install.
If it was such an issue for them, I’m sure they’d remove the GNU packages they pre-build and host for you. The premise of BSD is you don’t have to use the GNU tools. But they give you the choice.
(The point of my argument is: this is not an insurmountable problem.)