As somebody who really does not care either way, all this just sounds more like moving problems rather than solving a problems. At least, I don't think there are many Linux systems where you can safely remove /bin from the path just yet. I just checked. My Manjaro install has a /bin and it is full of files that look like I would not want to lose them. So, they fixed the /bin to /usr/bin thing for some packages but clearly not all packages in Arch. I bet/blindly assume that's true in Fedora as well.
I've always struggled with figuring out where stuff lives on the file system in different linux and unix derivatives. It's never where you expect/want it to be. I've used solaris, hp ux, mac os, and linux over the years. They all have similarly named directories, mostly for weird historic reasons. Is it /var/usr/god/knows/what or in /opt/foo/bar or in /usr/var/lib or /usr/share/lib. What about /etc, /usr/etc, /usr/local/etc?
You can take almost any 1,2,3, and 4 symbol permutations of share, lib, var, bin, opt, and sbin and probably find something that expects files to exist under that path. Reducing the number of permutations would probably be helpful.
People seem to just roll the dice and create some place where shit lives based on mostly just vague intentions, rules, heuristics, and interpretations of those associated with long dead unix variants from the nineteen eighties, weird naming conventions, and what not.
So, what's the rule here? Some 'special' packages should install to /bin and some other not 'special' packages should install to /usr/bin? Why? Is there any agreement about what constitutes a 'special' package? Is there a good functional reason for having both directories? And then the whole bin/sbin distinction is kind of arbitrary as well. Some binaries are statically linked, others are not and require libraries to exist in yet more shared directories on a library path. It all boils down to users requiring a PATH variables (and, inevitably, a lot of other/similarly named variables). And of course the order of paths is also super relevant and kind of the point. So you look in /usr/bin before or after you look in /sbin? It's all a house of cards. Brittle by design and convention.
The notion of taking a package and then fragmenting it over a multitude of shared directories is the problem that needs fixing. The role of a package maintainer is bridging those different notions of where stuff should live between different distributions with some convoluted scripts. It's a job that should not need doing and code that should not need to be written.
The main differences between linux distributions boil down how none of them actually having solved this problem that ended up doing only loosely similar but clearly different things for mostly obscure reasons. They don't agree on where stuff should live, how it should be moved/copied/linked there, where and how things are configured, etc. Most of these differences are kind of arbitrary and petty. /sbin, /usr/bin, /usr/sbin, /bin, /usr/local/bin, etc. who cares? I pretty much need all of these in my path for things to work as intended. I don't see a good reason for more than 1 of these to exist.
Apple kind of got this half right with the notion of mounting a package rather than installing it. Most applications install/uninstall via drag & drop. I always thought that was a neat idea. Of course, they then made it complicated by having /User//Library/* and /Library/* directories anyway. So, most applications leave a lot of clutter there after you drag them to the trash-can. And they also have the usual contingent of unixy directories. And package managers like brew, macports, fink, and whatnot that sort of carved out different places in the filesystem where their stuff lives. So, I wouldn't go as far as saying that Apple solved the problem. But it does look like progress to me.
Mounting stuff rather than fragmenting it all over the place is progress. Docker does this. And so do Flatpak and Snap. Flatpak and Snap are kind of tedious in their own way (e.g. opencl support is a PITA with Darktable and other packages that need that). But at least I have some stuff that I installed with those that actually works without having to be customized for every linux distribution.