Short answer: to ensure smooth transition from COM-less OLE 1 to COM-based OLE 2.
Slightly longer answer: the foundational use case for COM was OLE2. OLE2, as well as OLE1 before that, was based upon the idea that server applications register themselves in a common repository so that OLE client applications can find them without foreknowledge about the exact nature of the server apps. In other words, OLE was all about dynamic discovery of servers by clients, as opposed to working with a known server. Ergo, the need for a common repository of servers.
Now, the long answer.
COM was introduced together with OLE 2. OLE stands for Object Linking and Embedding, and like others said, it was an interprocess communication protocol for embedding pieces of content from one app (the server) in another app's document (the client). It was supported as early as 16-bit Windows 3.1.
Before OLE 2, there was OLE 1. Same business case, different UI paradigm, different underlying mechanism. In OLE 2, the server app would present its UI (e. g. the menu commands) inside the client app's window when the embedded content ("the embedded object") was activated, whereas in OLE 1, upon object activation, the server would have to create and display its own window, and implement a "save and return to the client" functionality to pass the altered piece of content back to the client app.
Anyways. To let users embed an object, the OLE client would usually have an "Insert Object" dialog with a list of available object types (Word document, Excel table, equation, graph, etc.). In order to present said list, OLE had to store them somewhere. Incidentally, those object types would roughly correspond to document types. If there's MS Word on the system, the "Insert Object" dialog presents "Word Document" as one of the choices, etc. Now, here's the crucial bit: even before OLE was around, Windows used the the proto-registry (then called "the registration database") to store a list of supported document types. When you double-click, say, on a Word document in File Manager, the logic would take a look at the registry to find out that the .doc extension corresponds to a Word document (the key
Word.Document), then figure out that the Word document supports an
Open verb and the executable for that is winword.exe, and invoke the latter, passing the file name.
When OLE 1 was introduced, rather than create another tally, they would extend the registration tree for a document type (AKA
ProgID) to support indicating the fact that it's embeddable. Some ProgIDs didn't have corresponding file extensions but were embeddable all the same.
OLE 1 was not a general purpose object framework (if there was one, it was well hidden and not documented). In OLE 1, there were only three predefined interfaces, rather than a couple dozen and an infrastructure for defining your own, like in COM/OLE 2. When OLE 2 came, along with a general purpose object framework (i. e. COM), they would extend the registration format even further. That's when the
CLSID key first appeared under ProgID. This enabled, among other things, server applications supporting both OLE 1 and OLE 2 side by side.
So applications like Word went from advertising their support for DOC files via the registry, to advertising their support for embedding (via OLE) its documents, to advertising their COM objects. All within the same datastore. In the same key tree, even.
OBTW, the original purpose of the registry - a means to track a document file extension to the EXE path of the host application - still stands to this day.
EDIT, to refresh our collective memories. I've downloaded a fresh copy of Windows for Workgroups 3.11 from MSDN, and installed it under DOSBox.
It comes with OLE1 and the registry out of the box.
olesvr.dll are both present under \Windows\System. Both
regedit.exe are present under \Windows. Running
regedit /v brings up the tree:
Notably, the Write text editor (a predecessor to WordPad) has an
Insert Object command/dialog in it, with three options - Sound, Paintbrush picture, and Package:
There isn't a trace of COM in the system. See how there's no
SoundRec, even though it's an embeddable object. Instead, there's
protocol\StdFileEditing\server, which was the OLE1 way of registering a server. None of the COM libraries (
combase.dll, etc.) are under windows\system.
CLSID isn't under the registry root.
Same story in Windows 3.1. Unfortunately, MSDN doesn't offer an English version for download. I've got a Russian one to check, it's all the same - OLE1 is present, COM isn't. Windows 3.0 isn't available on MSDN.