Don't forget, Linux/BSD/unix were originally server systems, which have found their way into the desktop area by keen users of these systems.

It isn't like when PC's first arrived, & DOS was the operating system, which then got a GUI bolted onto it - unix developed as a 'whole' system, not by having bits added piecemeal.

I think there are perfectly good reasons for /bin and /sbin to reside on the root partition, and for /usr not needed to be mounted at boot time.  And there are parallels for /lib and /usr/lib.  There are lots of different programs residing in /bin and /sbin (not as many as /usr/bin).  I think a fair fraction (major? most?) are programs which a casual user will never knowingly invoke in their lifetime  unless prompted.  Reading an article on:
__ cat dog
__Can't cat dog
May get someone to run cat, but normally users don't run cat.  Another class of programs in /bin and /sbin are programs that no casual user has any business running.  They might run them in an attempt to screw around with the system.  But in general, they should not even know of the existence of those programs.

The biggest namespace problem for user programs I have ever run into, is to have Arc/Info on a UNIX machine.  The info/texinfo documentation system has a namespace clash with the Arc/Info program to access data (info).  But as I was the only person reading documentation, it was easy to find a way to let most people find the Arc/Info info program.

We need to keep a simple boot process (with text files controlling what happens, and text log files).  So that a simple editor like vi can be used to fix boot problems.  We may need to get systems to boot faster, so that users can get their music sooner.  But I think booting off a SATA SSD goes a long way towards that.  If things are still a problem, get them booting off a m.2 SSD.

I have a friend who unintentionally screws up his /etc too often.  So, maybe the time is here for me to look at etckeeper, as I think it may help with his issues.  But this falls back into the /usr problem.

We don't need to have configuration information about packages that are not installed in the root partition, in the root partition.  So, we really need a /usr/etc filesystem to store all the /usr package configuration.  But in terms of what happens when the machine has finished booting, that information should be in /etc.  So, we have a /etc/usr filesystem, which is probably a symlink to /usr/etc, and we stick all the /usr configuration information there.

This probably reduces how many configuration files and directories are on the root partition a lot.  Maybe to the point where a person might dream of a common config (text) file format for all of those files.  And rationalizing the files so that a particular piece of information is present once (or as few times as is possible, and if multiple occurrences are possible, they are documented).  And maybe someone writes the etcedit gui, to allow a single application to display or edit all the data in the root partition of /etc.  And that gui goes in /usr/sbin.

Someone else want the soapbox to stand on?  :-)