The Unix model is built around the idea of lightweight processes that communicate with each other, through sockets, pipes, signals, and command lines. Historically, Unix didn’t have threads (the POSIX thread model is only about 10 years old IIRC), but processes on Unix have always been much cheaper than on Windows, so it was more performant to factor functionality into separate executables than to allow a single program to grow large and monolithic.
In COM, you define binary interfaces that allow shared-memory communication. COM is tied to an object-oriented paradigm. In the classic Unix model, you define stream-oriented interfaces that allow communication over pipes, without shared memory. Conceptually, this is much closer to a functional programming paradigm.
The Unix model encourages making small programs that can be easily coupled together by a lightweight “shell”, while the COM model encourages making large programs that expose “components” that can be reused by other large programs. It’s really an apples-and-oranges comparison, since both models provide benefits and drawbacks for different scenarios.
Of course, modern Unix systems can have COM-like facilities. Mozilla has XPCOM, a cross-platform framework built on the same principles as COM. GNOME for a long time used Bonobo, which is conceptually very similar to Microsoft OLE, which was the forerunner to COM. But recent versions of GNOME have been shifting away from Bonobo in favor of D-Bus, which is more of an event/messaging pattern.