When I started in the Unix world, it was relatively common to have overall Unix environments where you had multiple binary architectures and user home directories that were shared between machines with different architectures. Sometimes you had multiple architectures because you were in the process of an architecture transition from one Unix vendor (for example, from Motorola 68K based Sun 3s to SPARC based Sun 4s, with perhaps a SunOS version jump in the process). Sometimes you had multiple architectures because you'd bought systems from different vendors; perhaps you still had some old Vaxes that you were nursing along for one reason or another but all your new machines were from Sun.

All of this pushed both Unix systems and user home directories in a certain direction, one where it was sensible to have both /usr/share and /usr/lib, or /csri/share and /csri/lib, the latter of which was magically arranged to be a symlink to the right architecture for your current machine. For user home directories, you needed to somehow separate out personal binaries for architecture A from the same binaries for architecture B; usually this was different directories and having your .profile adjust your $PATH to reflect the current machine's architecture.

Those days have been fading out for some time. People's Unix environments have become increasingly single-architecture over the years, especially as far as user home directories are concerned. Partly this is just that there is much less diversity of Unixes and Unix vendors, and partly this is because cross machine shared home directories have gone out of style in general (along with NFS). The last gasp of a multi-architecture environment here was when we were still running both 32-bit and 64-bit Linux machines with NFS-mounted user home directories, but we got rid of our last 32-bit Linux machines more than half a decade ago.

(We had Solaris and then OmniOS machines, and we still have OpenBSD ones, but neither are used by users or have shared home directories.)

A certain amount of modern software and systems still sort of believe in a multi-architecture Unix environment, and so will do things like automatically install compiled libraries with an architecture dependent name (I was recently pleased to discover that Python's pip package installer does this). However, an increasing amount doesn't unless you go out of your way. For example, both Rust's cargo and Go's go command install their compiled binaries into a fixed directory by default, which only works if your home directory isn't shared between architectures. In practice, this is fine, or at least fine enough that both projects have been doing this for some time. And it's certainly more convenient to just have a $HOME/go/bin and a $HOME/.cargo/bin than to have ones with longer and more obscure names involving snippets like linux-x86_64.

(By 'architecture' here I mean the overall ABI, which depends on both the machine architecture itself and the Unix you're running on it. In the old days there tended to be one Unix per architecture in practice, but these days there's only a few machine architectures left in common use, so a major point of ABI difference is which Unix you're using.)