Why does /bin/sh behave differently to /bin/bash even if one points to the other?

bash looks at the value of $argv[0] (bash is implemented in C) to determine how it was invoked.

Its behavior when invoked as sh is documented in the manual:

If Bash is invoked with the name sh, it tries to mimic the startup
behavior of historical versions of sh as closely as possible, while
conforming to the POSIX standard as well.

When invoked as an interactive login shell, or as a non-interactive
shell with the -login option, it first attempts to read and execute
commands from /etc/profile and ~/.profile, in that order. The
--noprofile option may be used to inhibit this behavior. When invoked as an interactive shell with the name sh, Bash looks for the variable
ENV, expands its value if it is defined, and uses the expanded value
as the name of a file to read and execute. Since a shell invoked as sh
does not attempt to read and execute commands from any other startup
files, the --rcfile option has no effect. A non-interactive shell
invoked with the name sh does not attempt to read any other startup
files.

When invoked as sh, Bash enters POSIX mode after the startup files are
read

There’s a long list (currently 46 items) of things that change when bash is in POSIX mode, documented here.

(POSIX mode is probably useful mostly as a way to test scripts for portability to non-bash shells.)

Incidentally, programs that change their behavior depending on the name under which they were invoked are fairly common. Some versions of grep, fgrep, and egrep are implemented as a single executable (though GNU grep doesn’t do this). view is typically a symbolic link to vi or vim; invoking it as view causes to open in read-only mode. The Busybox system includes a number of individual commands that are all symlinks to the master busybox executable.