I think this is a pretty dangerous attitude, and it is really the only thing wrong with Linux, and probably leads to replacement of simple structure and functionality with a complex software suite that is merely more convenient, like systemd. "Let's change this thing because we want to, because it will improve performance 0.0024%"
Feature creep is what happens when restraint was not exercised.
IMO, since it really doesn't matter what the filesystem looks like, leave it be for standards and compatibility. Seriously, it takes, idk, maybe, a lack of humility to want to change fundamental characteristics of UNIX when the reasons for doing so are a little capricious.
I'm not really talking about the parent, fwiw. I'm talking about the crowd and ochlocracy.
There's plenty greybeards that for them "Linux" is a full screen terminal running emacs on decade-old hardware. "I don't use antialiased fonts, why the hell should I care about decent HiDPI support?" And then protest every time some working group tries to modernise and improve the Linux desktop. You see them every time on this forum.
I'm a greybeard, I've used Linux full time on the desktop for 20 years. I don't get this conservative, "we don't need it" attitude.
It's a historical quirk on linux, where there is no clear separation between "base OS packages" and "3rd party packages".
On FreeBSD the split is very real, anything in /bin/ ships with my OS and is maintained and updated by the FreeBSD team. Anything in /usr/bin/ comes from ports and is thus a 3rd party package I installed and can be safely nuked and I need to maintain/update it.
It was a historical quirk to start with. At Bell Labs, back in the early 1970s, Unix was being developed on PDP-11s with RK05 hard disks (with removable disk packs), which had an amazingly generous capacity of 2.5MB each. The Unix operating system had grown too big to fit on a single RK05 disk volume so they had to split it across two. Other operating systems of the period faced similar issues, but dealt with them in (arguably) more elegant ways – on IBM mainframes, OS/360 maintained a database ("catalog") mapping file paths (dataset names, to use the proper terminology) to volume names, so you could move a file to another disk without changing its path. True to Unix's penchant for simplicity, its authors decided instead to just split the OS into / and /usr. And the split survived long after they'd upgraded to more spacious disks.
Any other explanation for the split is essentially a retcon. Some of those retcons (even if, as other commenters have pointed out, not your own) may actually have become true – some of them may have been approximately true to begin with, and they influenced people's decisions, thereby making themselves more true over time. But its ultimate origins will forever remain this quirk of computing history.
I don't mean to shame you, I sometimes comment without reading TFA, and in your case you add a few more details that were not present in the article. I just found it interesting.