When sh is a symlink to bash or dash, bash limits itself to POSIX-compliance, so it should be 100% compatible with sh?

No, if /bin/sh is a symlink to bash bash enters just posix mode - from man bash:

When invoked as sh, bash enters posix mode after the startup files are read.

If you now search for posix mode at the bash manpage you'll see that some shell builtins like time or source behave differently. That is all. bashishms like writing function before declaring a function or using source instead of . still will work but the commands may behave differently.

So if /bin/sh is a symlink to /bin/bash all typical bashishms still work.

For a pretty extensive list of differences in the Posix mode have a look at the bash reference manual.

There seems to be some confusion around the Bourne shell. The Bourne shell was Unix shell decades ago, in the pre-POSIX days. Nowadays "sh" is an implementation or another of a shell that implements the POSIX specification, among which we have bash, pdksh, AT&T ksh, newer Almquist shells and their derivatives that have been made POSIX compliant (including the "sh" of some BSDs, other BSDs sh being based on pdksh and Debian ash (dash)). Even zsh has a mode in which it is mostly POSIX conformant.

The Bourne shell is not POSIX compliant, and can't be found on many system nowadays. Where the Bourne shell is found or where it's not, there will always be a "sh" that is POSIX compliant (and will not be the Bourne shell), generally in /bin while a notable (annoying) exception is Solaris.

Note that before the Bourne shell, and we're talking over 30 years ago, "sh" was the Thompson shell. We're not writing scripts compatible with the Thompson shell anymore. Similarly, we should stop thinking of "sh" as the Bourne shell.

Now "sh" is a specification, not many sometime incompatible variants of an implementation. That makes it a lot easier to write portable scripts. Just follow the specification.

That goes for "sh" and all the standard utilities (sed, cut, tr...)