/sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash.
The paths without /usr - /bin and /sbin - are available from the get go. It is the very first partition that is mounted, and what is guaranteed to be available if you do "init 1" or boot in single user mode. You can also do fsck from there (assuming the boot partition is not damaged). I don't know how this integrated with initrd (initramfs wasn't a thing yet). I think there was only one "base system" - either initrd was very basic, or the whole base was in initrd, or something similar.
The paths with /usr were managed by the package manager. Word of mouth was: don't install anything manually there. If you do (via make install), keep around the source so you can do make uninstall. But better install to /usr/local or /opt.
Why do you want to do that? Well, when you have a machine with virtualization you can share the /usr partition across all instances, physically. Which makes a lot of sense if you want to virtualize hundreds of Linux guests on one physical box: you memory map the /usr partition in hypervisor ram, you share that ram across all guests and wham you have snappy fast virtual machines with low physical footprint.
That was actually done, e.g. on IBM mainframes running "your personal web server" for thousands of users in one single mainframe. Fun times.
And only when the root partition could also be mounted r/o, with just an individual /etc, and when large partitions became doable as /, only then it started to make sense to abandon /usr
The split made lots of sense back in the days.
Or you could share the whole /usr over NFS to hundreds of diskless workstations, each having their own separate / (also shared over NFS). Remember that disk space was expensive back then; having hundreds of identical copies of the large /usr tree on the NFS server would be a huge waste.