What are the odds that some idiot will name his mutex ether-rot-mutex (2017)

There, it listed what COM components were available and how to start them. These components were meant to be available for all applications, so e.g. embedding 1 component like a spreadsheet in any other OLE application like avword processor could work, even for applications never meant to be connected together.

So it was at first meant as some meeting center, where anyone could drop anything for anyone else.

Meanwhile, the .ini files became a bit long in the tooth, so NT and 95 both adopted it as a config store.

When you use a meeting center for personal config, it makes sense that other passerby's would notice and start to mess with your config. This was both a blessing and a curse: It allowed all kinds of deep integration, but also injects all kinds of other peoples bugs in your code.

OLE 1.0 in the Windows 3.x era (which was a predecessor to COM, but not yet COM, and an evolutionary baby step between DDE [passing data through Windows messages] and COM) did not use "the" Registry but more complex DLL VTABLEs and INI files.

Meanwhile the NT Registry was built for the NT Kernel settings store, and primarily just the NT Kernel.

But COM did think to use the Registry as a central store of COM component registration. In part because the Kernel may need to call COM components sometimes. Largely because COM relied on it, the NT Registry was then backported (sideported?) to Windows 95.

So yes, I agree with you that my understanding is that COM is largely to blame for the inflation of the NT Registry from "just a Kernel data store" to something larger.

But my understanding is that while COM still needed a central registry, the Registry was never intended to replace INI files. That was a combination of accidents/mistakes by general developers at the time:

1. The Windows 1.x to 3.x INI reading/writing functions developed for a single user operating system had an unfortunate default to reading/writing files out of the current working directory which in Windows 3.x was still often C:\WINDOWS (but sometimes the application's install directory)

2. Windows 95 (correctly) added permissions restrictions to C:\Windows and C:\Program Files and asked developers to start using User folders instead (such as %LocalAppData% and %Documents%)

3. The INI APIs stopped working by default because they still defaulted to C:\WINDOWS or application folders for backward compatibility with Win16 apps.

4. Developers misunderstood this to mean that INI files were dead (because of those bad defaults causing the APIs to "glitch"/not work as expected/not work at all in Win32 apps)

5. Developers saw COM registrations going to the Registry and thought that was the replacement for INI files (in part because OLE 1.0 had used INI files in that registration way)

6. Because the Windows 95 Registry was already a weird port/fork of the NT Registry there weren't enough eyeballs on it from the NT Kernel team to try to push the brakes hard enough against the accidents/mistakes above

Certainly the cat is more than out of the bag this many decades later. But the moral of the story is that the Registry as used for application configuration (as opposed to mostly Kernel configuration) is an unhappy accident. Unhappy for the NT Kernel team that tried to optimize the Registry for Kernel operations only to see it flooded by application developers. Unhappy for application developers because it made install/uninstall more complex, baroque, and ugly than it ever needed to be in Windows 95+. Unhappy for users in how messy the Registry can get (when not sandboxed) and how easy to accidentally corrupt it can be when trying to "clean" it.