COM definitely has large levels of insanity wolf in it. It's a reference-counted object-orientated dynamically-typed self-describing interface for embedding any program in any other program ... written to target 1990s C.
Still, it enabled features that others have a hard time replicating to this day. E.g. MS OFfice exposes a ton of its functionality via COM for remote control and embedding.
COM was incredible for being able to hack bits of various programs together.
I worked on a spike once to try and get a modern web browser embedded in a proprietary business basic language who's UI toolkit only exposed some COM/OLE stuff.
It was an unholy abomination of unmaintainable software, but it worked and worked well. It made me think a lot about how things would have looked today if ActiveX managed to keep it's foothold.
There was a lot wrong with ActiveX, starting with the fact that it was proprietary and Windows/X86 only, but the basic concept of cleanly embeddable controls was extremely sound and is something the modern Javascript world is only slowly groping towards.
The biggest problem is that they start with something that's supposed to be part of application software on your PC and then try to blacklist the dangerous bits and put everything else on the web. We already knew by then that blacklisting is a terrible idea in security and won't work.
The meeting should have gone like this:
Manager: We're going to put COM on the Web!
Engineer: What about this COM function that deletes files?
Manager: We'll blacklist that.
Engineer: Or this one that reboots the PC?
Manager: Blacklist. In fact I'm assigning you the job of making the blacklist.
Engineer: I think there's an unlimited number of problematic features of COM.
Manager: Good point. OK, ActiveX is cancelled. Thanks for your time, good meeting everyone, make sure to implement PKIX correctly so we don't cause more holes there too.
You joke, but I started with Win32 programming then later moved to MacOSX and the COM/Objective-C link is pretty clear.
My guess is that a team at Microsoft in the 90s saw the need for a cross-process runtime object system, saw Objective-C and thought to themselves "Hey, this Objective-C is pretty useful but it doesn't suck enough to be part of Win32. Lets fix that - GUIDs, GUIDs for everyone!."
There's an amusing video on youtube where Steve Jobs is demoing remote Objects on NextStep and (I think) Openstep on Windows, and having a laugh at MS since Next managed to get remote Objects working before MS got their Remote OLE (aka DCOM) working. Steve calls it Doh'LE.
The only different thing that COM had was support for scripting the objects via IDispatch, but that was such a pain (VARIANTS !) that only those really needing it bothered.
MS were also very proud of their MTS where an on the fly proxy object was created, but even that was inspired by Remote objects.
However they really jumped the shark when they made it possible to create COM objects from Visual Basic - the endless grief caused whenever a VB developer decided to change any parameters on the interface and caused all GUIDs to be regenerated and a big fat binary with all revisions of the code. They then created a tool to strip that all down to just the last version, thereby totally removing any backward compatibility - which then caused other random components to fail.
