Understanding the bin, sbin, usr/bin , usr/sbin split

This is a little bit disingenuous. I can certainly see the point that all of this separation is unnecessary on a typical modern desktop system, but several of the paths you listed in support of your argument are not actually specified by the FHS, nor do they even make sense.

Of the paths you mentioned, there is no such thing as:

    /usr/share/bin
    /usr/share/local/bin
    /usr/local/share/bin
    /usr/local/share/lib
    /usr/share/lib
    /opt/bin

All the paths that involve `share` are for non-executable data, so `bin` and `lib` subdirectories of these don't make sense. That's not to categorically say that there isn't any OS that provides them anyway--I've seen plenty of Linux distros with disorganized file systems--but that's a problem with the distro, not the FHS as a whole.

The `/opt` hierarchy is pretty much the wild west, I'll give you that. It's basically like `Program Files` on Windows; packages get an entire hierarchy to themselves. Most of the software I've seen that installs to `/opt` is Linux ports of Windows software, where the authors were either ignorant of the Unix way of organizing things, or simply didn't want to bother conforming with the norms of a different platform.

Incidentally, one of the reasons I prefer Arch Linux over some other distros is that the organization of the file system follows the standard and actually makes sense. Things are always where I expect them to be.

Your overall point may have some merit, but it feels a little like you're reaching for support for your position by making up wacky, confusing paths that don't actually exist.

FYI, the linked post completely contradicts what you wrote.

It drives me crazy every time I'm on a Linux system and ifconfig is in /sbin, and not on users' PATH, even though the no-argument form works perfectly fine as a user.

A distribution that does just that is NixOS (http://nixos.org/nixos/). It has to, because it's purely functional (new stuff shouldn't overwrite any of the old stuff) and it has to support several different versions of the same package being installed at the same time.

It is awesome, especially the easy rollback and that you can specify an entire system with a recipe. Still, it feels strange for us who are used to mainstream Unix systems.

And why / /usr split still makes sense:

If it's needed to boot, it goes in root: boot images (including root filesystem) can be initrds, bootp images, flash sticks, or other similar tools. Maintaining the discipline of keeping what you need in / and what you don't need to boot in /usr helps when you're trying to minimize boot images, troubleshoot, and/or just simply keep things comprehnsible.

Different partitions can be mounted differently: There are still a few things in the root FS which are written periodically, especially in /etc. By contrast, /usr is largely static. They can be mounted writeable vs. read-only (dittos /boot BTW). Root may require device permissions. Both require suid (but /home doesn't). For various degrees of security and self-inflicted foot-gunshot incidents, mounting with minimal permissions can be useful.

Not all bootloaders handle all filesystems and storage: Applies more to /boot, but particularly for exotic / networked storage, ensuring that early-stage bootstrapped filesystems are accessible with a minimum of fuss can be useful.

The arguments from Fedora about the ability to manage a system from within an initramfs are particularly amusing given RHEL's traditional use of a non-interactive, script-only shell: Yes, that's right, you can't exit out of the initramfs shell to do maintenance. Debian's 'dash' shell is not only smaller than the RHEL equivalent, but supports interactive use. Go figure. (Apologies if this has changed recently but it was true as of the past year or so).

Shared/network mount purposes: A read-only, shared /usr filesystem can be used and accessed by multiple systems. Maintaining the root /usr split ensures that local system commands (if necessary) can be provided independently of the shared bits.

While the origins of /bin vs. /usr/bin lie in what are now largely irrelevant disk capacity constraints, there are a number of reasons why maintaining the split continues to make sense. As has been noted, a fair bit of hierarchy persistence is on account of differentiating between differently-managed packages at different parts of the system. As the guy who gets to come in, comprehend, rationalize, and clean up systems afterward, I can assure you that a logical ordering and seggregation does help markedly.

For distros with a decent package management policy and toolset, there's no particular problem to maintaining this. $PATH variables already make the end-user impact essentially nil.

For those who wish to combine things, union mounts or symlinks can certainly be used, again, with little or no end-user impact. For some embedded/small systems this makes sense. There's no reason to force one-size-fits-all on everyone, however.

I'm also generally opposed to arbitrarily adding top-level directory trees. The naming rarely stays consistent over time (business unit / institutional name changes are notorious). And it tends to complicate matters especially concerning backups and where essential local data lives.

Tempest in a teapot.