Speaking of Explorer, one of the classic ways to end up with a Windows system that's slow for no readily apparent reason is shell extensions. Either on the rightclick menu or in the thumbnail engine. At one point I had a folder I couldn't navigate to without getting an error popup that mentioned Nvidia in it - a chain of handlers had been installed such that JPEG decoding was delegated to the graphics card, so trying to create and cache the thumbnail of a corrupt file crashed in an unrelated-looking place.
It's the wrong solution to an old problem: having your configuration in hundreds of .INI files was a problem because opening and reading files took a long time. Instead of solving the problem and making opening and reading hundreds of files fast (which would be awesome for a number of other uses of a computer) they created new file that every application would read and write to. It seemed like a great idea at the time.
Every problem has a solution that's simple, elegant, and wrong.
This seems to be the correct answer, but not for the reason you think ("outdated information"). The registry is a highly indexed database, because it needs to be quick at answering if say a low-level kernel-level driver needs something in real time for an operation. Many of those indexes are variations on Most-Recently-Used (MRU) caches. The more applications that make random queries to the Registry, the more those MRU caches churn and the more likely the MRU caches are full of small, one-off application data versus important stuff that needs to be queried as quickly as possible. (Over time Windows has seemed to work to compensate by changing indexing strategies, but at a high level a lot of the slow down issues with registry still boil down to index problems.)
The Registry wasn't intended to be a general application configuration store, per the original registry usage guidelines. Certainly that ship sailed.
(Also, the key problem with INI files was not that opening/reading them took a long time, it was the same centralization problem: almost every Windows 3.x application stored their INI in C:\WINDOWS for a number of dumb reasons. When Windows 9x started enforcing basic directory ACLs and not every program under the sun could read/write to arbitrary files in C:\WINDOWS, people scurried for the Registry as that seemed the closest to what they were already doing, squirreling config data in C:\WINDOWS for dumb reasons. It took a while for developers to realize they should just put config files in whatever format they prefer in %LOCALAPPDATA% or such like and stop trying to centralize them.)
In the Windows 3.1 days I had some interesting problems when importing data into an MS Access databases that would contain reports for our senior execs to read while offline (the web was not a thing back then) and import throughput slowed down to a near-halt after 30 megs of data or so. Our solution was to do the import in chunks, and defragment the database between them.
Why is your software looking at registry entries that it didn't create?
I may want to know where Photoshop is installed to I can register a plugin. Or know about the printers installed. Or know more about the environment than the OS is willing to tell me. Or those may be entries that older versions of other applications of mine did create. Or Windows. Or older versions of Windows.
There are many reasons to look into registry entries that aren't the ones you wrote.
Sure, it happens rarely - but it really depends on your usage patterns. If you often have to try out software on a regular basis (I've always used Windows VMs for work stuff when I needed to evaluate things from $randomVendor) it might accelerate this. Or sometimes it's a piece of hardware. yes, some are 90s tales but to some degrees it has persisted.
And it is just a hierarchical database, nothing special about it. It shouldn't be very different than accessing files on the file system.
(there were some bugs at the past that caused Windows Explorer to slow down but those were fixed long ago and they were just bugs with a single application, not something inherently slow with the registry itself)