I think the bigger reason may be this, from the original article:
> Most folks at Claris, Apple’s application group, didn’t want it at all, seeing it as an enabler for competition to Claris’s office suite product, ClarisWorks.
The trouble with composite documents is that it goes against the market's tendency to accrete power to the incumbent.
* If you're WRITING document software, the composite document model adds a bunch of development complexity for (mainly) the purpose of opening doors for your competitors to eat away at your lock in. From a marketing perspective, If I'm writing document software I'd probably much rather you use _my_ spreadsheet than whatever spreadsheet you want. From a support perspective, it's easier if I own the code on both sides of an embedding. From a development perspective, it's easier to add more differentiated features if I don't have to force everything through a common document embedding model, etc.
* If you're USING document prep software, the composite document model adds complexity to the way you install and buy software, the UX for the software, and then what you can do with the documents you create with your carefully curated software suite.
There are ways that all of this can be addressed from a technical perspective, but the end reality is that the costs are too high and the return too limited to be useful.
(As you point out, OLE2 has seen a lot of market acceptance, but a lot of that comes in the context of MS Office. Despite the availability of embedding technology within OLE2, The market didn't gravitate to hand-curated sets of best-of-breed office software. The market gravitated to MS Office with specific add ons for specific use cases. Even then, in settings where not everybody had those add on packages, there was a tendency to push documents to fit into whatever stock MS Office would support.)