Microsoft could have exposed the registry as a filesystem. R: drive or \\winreg\ or whatever.
They kind of have with Powershell, but that's Powershell-specific. They could have made it part of the OS so it was available to all apps, like /proc and /sys on Linux. And then you could do all those things to them too.
If it were actually a filesystem, it would be composed of File objects, so you could manipulate it using the exact same API calls you use to manipulate files – which would mean that tools/utilities/apps which know how to manipulate files would just magically work on registry keys too.
While in the registry it's like 5 layers deep and you need to figure out the vendor name along the way.
Also, regedit supports Ctrl+F.
Sometimes it's /etc/$subdirectory/$toolname, doing that very many-layers-deep thing that you describe.
Sometimes, particularly on the BSDs, it's /usr/local/etc.
Sometimes it's ~/.config/$subdirectory/$subdirectory/$thing . Or, if you are lucky, it follows the XDG rules for locating the ~/.config part.
Sometimes it's ~/.$toolname .
The irony is that all of the arguments about where the files are fall apart and miss the point, as the Windows registry hive file system is far more standardized than Linux-based operating systems and the BSDs are.
The real discussion point is whether a structured hierarchical database of key-value pairs with typed values, accessed through an operating system API, is better as an actual database file format, with all that that implies for things like indexing and the elimination of quoting rules, text parsing, and escaping; or as text files just like it used to be with the old loads-of-.INI files system of DOS-Windows 3.
OSes are a superb use-case for recursive, object-oriented, hierarchical setup and configuration, but no; Unix and friends, and the programs that run on them, insist on spewing a million-odd .ini, .cfg, .json, .yaml, .xml, .whateverml files all over the filesystem and then 'hiding' them with the leading full-stop.