DCOM is built on top of MS-RPC which is originally a DCE-RPC variant yes, but DCE-RPC isn't object oriented and all the interfaces inside Windows are. You can't just open a local socket and speak DCE-RPC to Windows services, you have to use COM.
Am I the only one who still remembers Windows existed before OLE and later COM? The original RPC in Windows was based on sending messages to windows (and suddenly the name of the operating system makes complete sense), each message having, besides the target window and the message type, a word parameter and a long parameter. If you needed to send more data, you allocated memory from the global heap (which was shared between all processes), and passed the handle to that memory as one of the two message parameters.
There are still leftovers of that original design all over the system; IIRC, some COM functionality make use of a hidden window to send messages between processes.
COM (ab)uses window messages primarily for objects with thread affinity. Microsoft don't (didn't?) have a standard way to post lambdas to a thread's message loop like most platforms do, so they hack it by using GUI messages to a hidden window.
The RPC protocol used by Windows between machines (e.g. for registry access, file sharing, setting permissions, etc.) isn't COM-based. Similarly, the RPC used internally (e.g. to talk to win32k) isn't COM-based. My Windows knowledge is quite stale but when I was developing for it COM was used for APIs but it wasn't much used for RPC.
COM is used both to expose in-process APIs that you invoke and also to do RPCs between services, but that's an implementation detail that only sometimes matters. Historically most stuff ran in the kernel (not any more) so there wasn't a big need for inter-process COM. These days there's more microkernel design but the underlying APIs were all 1980s era flat C APIs so indeed COM is of less relevance for remoting them.
