I'm just curious. Has anyone tried removing LD from the picture all together? How did it run? Performance? Memory usage?

I try different setups on occasion. In fact, years ago (mid 2000's), even before people started ranting about it on the internet, I started building my LFS with a merged /usr and have never went back. (Yes, even with sysvinit...) It reduced so much complexity, especially during the build. Basically, my systems look like this:
It gets rid of all those library symlinks /lib/*.so{,.*} -> /usr/lib and more than a few from the bin directories. I've never had a need for the split user and commercial Unixes got rid of that stuff in the 90's. (Why its existence confused me on Linux.)

To answer your question on behalf of others, I think the answer is no, they didn't. I did mistakenly not transfer in chapter 6 from the old toolchain of the host OS to the newly built system, and that came unstuck, forcing me back.

Yes, you are correct, there is no need for a separate / & /usr partition these days. It was a good idea originally, but memory and disk space have increased beyond all imagining over the decades.

As for doing everything statically, yes, you can do it, and probably get away with it too. But what's the benefit of every program holding chunks of the same libraries. Show me the advantage.

Johnny Cash had a song about a shoplifting factory worker at GM who gradually shoplifted a car So he had a model '48,'49,'540,'51-->64(?) car. Modern pcs are sufficiently forgiving to stand up an OS like Johnny Cash's car, but I fail to see the improvement. The symlinks in most cases are to the same dir, unless someone's been hacking the system already. Then you might get lib -->/usr/lib or vice versa

You've never really thought about it, have you? Let just say that there would be many implications; some good, some bad, and many that would surprise you.

Here is one example: Suppose I created an app that used say... 5 or 6 different libraries in addition to libc on a current Arch Linux system. When compiling I chose static linking and the flags -march=x86-64 -mtune=generic. That binary's only requirements are only: an amd64+ processor, a Linux kernel > 3.2 (or compatible ABI), a recent glibc and a posix shell (assuming it uses one). Whether or not you have those 5 other libraries is unimportant, what versions of them you have is unimportant. Them having optional cross linked features is unimportant. (example: mesa-cairo-gl build loop) The application will run regardless.

In recent years I've seen a number of people talking about static linking in container apps for just this reason. This however, is not a new idea, look up something called slinky if you're curious. That said, with memory getting cheaper and on-die caches getting larger. I wonder how long until people decide that building in such a way, regardless of the extra runtime resource requirements, is worth it. Because, it reduces a ton of complexity in the system. i.e. ABI over API.

Received wisdom is that it's not a good idea. People most often cite memory, but that's increasingly a moot point.
Your point about containerized apps makes sense, but only in the case of malicious libs loaded on your hd, which implies a write on your system using root permissions has been accomplished, and your own system cannot be relied on. That's a Windoze type issue, not a linux one, surely?
VMs are in common use containerizing apps on servers. Hack the app, and all you get is an empty OS. A static system doesn't offer that level of protection. Admittedly, Meltdown & Spectre opened issues there, but Intel, AMD, & ARM seem well on the way to closing them.

Why don't you ignore the naysayer (me), build the system, and find out? Back up, disconnect the disk, Drop the firewall, and get the nasty guys in to have a go?

I use a similar filesystem layout except lib64/ is a directory on rootfs as per book and no lib64 in /usr. This greatly reduces the number of instructions to complete chapter 6. And, it has the added benefit you actually have to think about what those post-install 'adjustment' commands are doing and either omit them or adjust for your own layout (e.g. ncurses and bzip2 come to mind).

I've been having similar thoughts about other deviations from the book. I think that is the whole point - once you are proficient and actually using your system - think about how to 'break the book' (and not trash your system). There are a lot of --disable-static commands in B/LFS. I use Crux pkgutils for package management and looking at their build scripts, they usually build the static libs as well.