Welcome to the computer business! OCX's have to be registered due to the registry. I realize that's a bit of a circular reference. OCX's are binary code that conforms to the Component Object Model (COM) programming model. The key tenant of COM is that they are only partially self-describing.
When your program requests a COM object, it asks the Object Linking and Embedding (OLE) subsystem of the operating system for the object. OLE's job is to read the HKEY_CLASSES_ROOT key from the registry for the requested object. A Globally Unique Identifier (GUID), a 128-bit number, identifies the object itself. When an OCX registers itself, it declares it's GUID and where the OLE system can find that particular .OCX file. In essence, you can think of the registry as the translation layer.
Since I can read minds, some of you are wondering what the difference is with .NET. Where a COM object is not self-describing, a .NET object is completely self-describing. Where a COM object has data in it's binary as well as the registry to describe it, a .NET object has every bit of information about itself inside the binary. (By the way, this information in .NET is called the meta-data.)
With meta-data, anyone can load up a .NET object and using a technique called Reflection; you can find out exactly what methods and properties that object supports and call those methods and properties with the proper parameters. This works even if there are all sorts of custom data types and whatnot in the .NET object. With COM, the only way you can call unique methods on an object is to manually program them. The only way you can call methods and properties on a COM object is to have a priori knowledge those methods and properties and manually writing to code to call them.
This was first published in March 2003