For years now, I've used a merged /usr setup on my LFS. Today I'm going to try it the other way. After all, back in the original UNIX setups, /usr came about because / was full. I'll let y'all know how it turns out and post instructions if anyone is interested.

When going through my notes, this simplified the edits to the base LFS book quite a bit. Whether or not I'll dump the creation of the /usr/local hierarchy I still don't know. (Though I don't use it.)

If what you mean is a single file system on a single partition, that is common on Virtual guests. It can certainly work, but leaves you vulnerable to the "file system lockdown" effect. This is where one file or file tree fills up all of the free space and locks your machine or causes a crash. The storage separation with trees in different file system is designed so that some of the file systems can fill up and it is only inconvenient, not a full stop. Go ahead, but be aware that you are eliminating one of the design protections of your installation.

LOL! I love this... Having a split-usr (/bin and /usr/bin) is not some ancient UNIX guru master wisdom the developers specifically planned out. Back at AT&T, the root fs (/) disk was getting full, so they added /usr. So, it was basically a hack for the tiny disks they were using back in the 1970's and even commercial version of UNIX stopped doing this by the late 1990's. Though, this was not the case for Linux, where every idiosyncrasy of ancient Unixes are treated as if they are some mythical canon that must be followed lest the operating system be fundamentally flawed. How about this: if you don't want the system to freeze over disk space, then putting /home on a separate partition and putting quotas on / is far more practical than splitting up /bin into /bin and /usr/bin.

Glad you love it, but you might note that I made no specific mention of bin directories. In fact, I did not discuss directory segmentation at all, my point was file system segmentation. The ones important to isolate are those holding logs, spoolers, and cache. It pays to attend to temp files also, when those are physical storage mounts.
As for /bin and /use/bin, how do they matter? Some distributions make one a link to the other without blowing up. Only important distinction is that the /bin mount should always be available at boot. /usr/local may mount after boot or near the end of boot. If that does not matter to you, then go for it.

Oh okay, I thought you were one of the split-usr "purists". :P

/home, /var, /srv, and even /boot make sense on different partitions. Personally, I always put boot and home on their own. But there are those who believe /{,s}bin,lib* and /usr/{,s}bin,lib* should always be separated when I find that notion... romantic at best. There might be a use case for doing this in unusual things like PXE booting, though I think an initramfs would be better, but I'd say the vast majority of Linux users have no need to split those off. That said, when someone brings up merging them, I'm use to the UNIX philosophy guys rolling in and going on about how they did it at AT&T and how it should still be done that way because.

Remember the famous principal in architecture "form follows function"? Well, it applies in IT design of hardware, storage structure, networking, and other disciplines as well. Segmenting the file system structure evolved: sometimes by combining plans but at times because the function cried out for isolation to protect the system. The better you understand the usage (function) the better you can predict what you can change without unacceptable risk.

If you are using a throw-away virtual guest, or LIKE reinstalling your OS, then risk need not be considered. In this case crashing your system is an educational opportunity. The more stability needed, the less risk is acceptable and the more you need to THINK about your system when making these decisions.

The storage plan you describe makes some sense to me. I have workstations where there is only one file system (I like reinstalling often) and WORK workstations where /boot, /home, /, /var, and /data are separate.

On my servers it depends upon usage: normally /boot, /, and some variation of /data. /home gets one ONLY if the users needs a home folder in the OS: on some systems they exist only in the application space (on /data). /local gets unique space if it hosts unique and custom applications or operations that can grow. Very special operations (database perhaps) may beg for an additional unique storage. ALL of these plans are only for SERVER systems, and are serious overkill for normal workstations.

Separating /bin from /usr/bin makes little sense these days, and some distributions have eliminated the difference. Separating /bin from /usr/local/bin DOES make sense if you have unique and non distribution software that you should segregate.

If you are building your own system, and your own plan, then you can make your plan fit your planned usage of the system. Just try to make sure you do not shoot yourself in the foot.

This is a Linux From Scratch system, and I've deviated from the book instructions for years running my own merged-usr variant. I was trying giving the reverse a try. However, it seems that merged-root is far more trouble than merged-user so I abandoned it a few days ago.

Merging like this...

As I have been doing for years now appears to be far simpler than what I was trying here...

If anyone reading this is thinking of trying it, here are the biggest issues: Autotools/CMake/Meson with prefix=/ creates several issues that don't exist with merged-usr. Namely, you don't get share, include and libexec created in root. --exec-prefix might seem like an option, but not every package appears to handle this properly. Especially those with weird custom configure setups that call stuff like python or their own shell scripts to do what autotools/meson/cmake would normally do in the background. I never got as far as trying to do merged-root with larger packages that contained their own build tools, header paths and rpath setups like Boost, QT or Palemoon Browser, so I can't speak as to how much difficulty that would create. There were other issues, but those are the most prominent.

All-in-all, merged-usr is far simpler than merged-root because of the current state of the FHS and the long standing default of: ./configure --prefix=/usr