They licensed Spider Software's TCP/IP stack. And you have no knowledge that Spider leveraged BSD code. You're probably too young to remember, but there were many vendors making TCP/IP stacks back in those days. Some based on pre-existing stacks, others from the ground up.
I'm unsure as to why you're making unsubstantiated claims and sticking with them. You have zero proof that the claims you're making are true. I'd love to have the source for Spider's TCP or at least have a contact that worked on the stack to ask, it's interesting history. I don't care one way or another, it was a very temporary stack that didn't make it into 3.5 where the entire stack architecture changed (no longer based on SysV STREAMS).
You're not seeing "pure" FS performance. You're seeing all of the abstractions between you and the file system.
To get more of the abstractions out of the way, you want DevDrive. And don't use Explorer.exe as a test bed which has shims and hooks and god knows what else.
What happens if you have an extensible app, say Microsoft Office, which enumerated it's own subkeys to discover 3rd party plugins?
What if an app provides COM services and needs to write that to a centralized location that is enumerated to discover available COM services?
What if your app happens to be a god-awful HP Print Center app with it's own print drivers and a Windows Service, where it needs to write to a central location that is enumerated for device drivers and Windows Services?
It was introduced with Windows PowerShell 1.0[0]. A text editor would need to directly support managing the registry, but you can read/write/search/do terminally-stuff to the registry via PowerShell.
The term we're looking for is a PSProvider of which there are many. There's even a PSProvider for SharePoint Online[2].
The registry was capable of being compacted, negating the need to defragment it. This was done via the standard Windows Backup utility provided OOTB.
As for performance, the registry was mapped in paged pool memory[0]; only sections in-use needed to be mapped. Other hives were volatile and never persisted to disk. When data is added to the registry, the paged pool expands to accommodate. Maximum registry size is based off of installed memory, up to a limit.
Registry subkeys are organized alphabetically in an internal list; searches are binary searches rather than using an index. Searches begin in the middle of the list and go up or down based upon the alphabetical value being searched for (so start at 50% -> up/down, split remaining list 50%, up/down -> repeat until found).
You can find more info in Chapter 4 of Windows Internals 4th Edition.
Needless to say, none of the concerns you presented were valid back in the dark days.
That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names.
Generally, 3rd party developers don't use a bunch of GUIDs for keys. Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there).
Using Windows Installer, this is easily accomplished. The Msi database _does_ track individual files and registry entries. If you're using another installer, or the developer allows their app to write something somewhere that isn't tracked by their installer, you're going to get files left behind.
macOS is especially bad in this respect. Bundles are great, until you have a ~/Library full of files that you never knew about after running an application.