Read the Criticism section:

"XPCOM adds a lot of code for marshalling objects between different usage contexts (e.g. different languages). This leads to code bloat in XPCOM based systems. This was one of the reasons why Apple forked KHTML to create the WebKit engine (which is now used in several web browsers in various forms, including Safari and Google Chrome) over the XPCOM-based Gecko rendering engine for their web browser.

The Gecko developers are currently trying to reduce superfluous uses of XPCOM in the Gecko layout engine. This process is commonly referred to as deCOMtamination within Mozilla."

But my original top comment was about RPC and the compound document format (OLE as example), not about COM.

Apple had a compound document format too (death since 1997): http://en.wikipedia.org/wiki/OpenDoc

"OpenDoc's flexibility came at a cost. OpenDoc components were invariably large and slow. For instance, opening a simple text editor part would often require 2 megabytes of RAM or more, whereas the same editor written as a standalone application could be as small as 32 KB. This initial overhead became less important as the number of documents open increased, since the basic cost was for shared libraries which implemented the system, but it was large compared to entry level machines of the day. Many developers felt that the extra overhead was too large, and since the operating system did not include OpenDoc capability, the memory footprint of their OpenDoc based applications appeared unacceptably large. In absolute terms, the one-time library overhead was approximately 1 megabyte of RAM, at the time half of a low-end desktop computer's entire RAM complement.

Another issue was that OpenDoc had little in common with most "real world" document formats, and so OpenDoc documents could really only be used by other OpenDoc machines. Although one would expect some effort to allow the system to export to other formats, this was often impractical because each component held its own data. For instance, it took significant effort for the system to be able to turn a text file with some pictures into a Microsoft Word document, both because the text editor had no idea what was in the embedded objects, and because the proprietary Microsoft format was undocumented and required reverse engineering.

It also appears that OpenDoc was a victim of an oversold concept, that of compound documents. Only a few specific examples are common, for instance most word processors and page layout programs include the ability to include graphics, and spreadsheets are expected to handle charts. [...]

But certainly the biggest problem with the project was that it was part of a very acrimonious competition between OpenDoc consortium members and Microsoft. The members of the OpenDoc alliance were all trying to obtain traction in a market rapidly being dominated by Microsoft Office. As the various partners all piled in their own pet technologies in hopes of making it an industry standard, OpenDoc grew increasingly unwieldy. At the same time, Microsoft used the synergy between the OS and applications divisions of the company to make it effectively mandatory that developers adopt the competing OLE technology. In order to obtain a Windows 95 compliance logo from Microsoft, one had to meet certain interoperability tests which were quite difficult to meet without adoption of OLE technology, even though the technology was largely only useful in integrating with Microsoft Office. OpenDoc was forced to create an interoperability layer in order to allow developers to even consider adoption, and this added a great technical burden to the project."

And there were others too: http://en.wikipedia.org/wiki/Compound_document

This is more of a ideological difference in how things should, and can, be done. For a long while, the only way to reliably edit Word documents was using Microsoft Word (half of it being undocumented, and half of it being documented as "this is supposed to do whatever Microsoft Office does"), so you effectively needed to embed Word within your program in order to reliably edit Word documents. A lot of that changed

In the open source world, there are canonical tools, but traditionally it's been about the format being open and accessible explicitly so you don't need to rely on/run a third-party program to do the manipulation, rather either roll your own manipulation routines following the documented standard (thereby strengthening the ecosystem with multiple implements, hopefully) or use a library (that the canonical tool may be based on/also use).

Both schemes have their advantages and disadvantages. It would be an interesting study in why/how the different ecosystems evolved to favor one over the other, how that has changed over time, and how that's influenced the size and robustness of the respective ecosystems. There's probably a lot of influence on the Windows/RPC side coming from the canonical tools being primarily interface GUI interfaces, which is then natural to want to "drive" or "control" remotely, vs "headless" interfaces that are able/meant to be scripted as a first order requirement.

KDE has KParts and GNOME has Bonobo. The latter is apparently deprecated, but it used to be used by the desktop panel for embedding widgets running in separate processes.