The short answers are, yes, it was done for compatibility (lots of programs referenced
/bin/ed), and in the early days
/usr/bin contained totally disjoint sets of files.
/bin was on the root filesystem, a small disk that the computer's boot firmware had to be able to access, and held the more critical and often-used files.
/usr/bin was on
/usr, typically an entirely separate, larger disk.
/usr, at first, also contained users' home directories. As
/usr grew, we would periodically replace its drive with something larger. The system could run with no
/usr mounted, even if wasn't all that useful.
/usr's disk (or disk partition) was mounted after the Unix kernel had been booted and the system was partway through the user-mode boot process (
/etc/rc), so programs like
fsck had to be in the root filesystem, generally in
/etc. Sun had even rearranged
/usr so that a shared copy of
/usr could be mounted read-only across a network.
/usr/tmp became a symlink to
/var was either on the root filesystem or, preferably, on another partition.
I believe it was Sun that decided, at one point, that it wasn't worth heroically trying to have a system be able to come up if its
/usr was trashed. Most users either had
/usr on the same physical disk - so if it died, both filesystems were toast - or had
/usr mounted read-only from a server. So some critical programs used for system boot and maintenance were compiled statically and put in
/sbin, but most of the programs in
/bin were moved to
/bin became a symlink to
System V prior to R4 didn't even have symlinks. Sun and AT&T worked to combine SunOS and SVR3, and that became SVR4 (and Solaris 2). It had
/bin as a symlink to
So when that web site says "On SysV Unix
/bin traditionally has been a symlink to
/usr/bin", they really should have said "On System V Release 4 and followons, ...".