The functionality goes back to 1996, but I've never seen an implementation of the "object store" part of the system by anybody. I'm not aware of Microsoft releasing a reference implementation, either.
It wouldn't be a tremendously hard thing to write. It just needs to receive POST requests and return a redirection to the "best" object URL (based on the requested MIME type, CLSID, and taking into account the language and MIME types the client says it's expecting).
I'm not sure I see the advantage to using this functionality, though. What are you looking for?
Addt'l integrity assurance? You should only be allowing signed controls to install anyway, so it's not like having your own repository is going to allow you some addt'l measure of integrity assurance.
Decreased bandwidth utilization by clients? Downloads of controls are done over HTTP, so a caching HTTP proxy would minimize the bandwidth used in code downloads as effectively as redirecting clients to a central object store.
Using a central object store doesn't really do anything with client user rights, which is what I see as the major problem associated with control installation.
Presumably your users don't have "Administrator" rights so they can't install arbitrary code (machine-wide) anyway. If you have "modern" versions of Windows you can use the ActiveX Installer Service to "whitelist" ActiveX component installs for non-Administrator user. You can do this w/o a central object store.
IE 8 does allow non-admin ActiveX control installations (installing to HKEY_CURRENT_USER instead of HKEY_CLASSES_ROOT) but the user will only be able to mess up their own environment with these installations (provided, of course, that they don't have "Administrator" rights). This functionality can be disabled by Group Policy, as well.