"Sensible" cuts across a lot of axes. Those comparable tools, for the most part, didn't have the same sorts of OLE wizardry that are really pretty useful for normal, non-technical people. That comes at a cost of technical complexity.
By "sensible": it was possible to implement independent, reliable, read-and-write capable tools for these formats.
OLE was a tremendous boon to lock-in on the part of Microsoft. It was useful, yes, but hardly flexible. There are other tools which offer comparable capabilities without the lock-in elements.
Hal Varian (currently Google's chief economist) wrote the book on vendor lock-in, and how to both secure and avoid it (as a customer) in the late 1990s.
There weren't comparable tools in 1990. There still aren't, for a lot of things--something as simple as embedding a spreadsheet table in a document is still not really feasible except through similarly closed mechanisms.
Your attempt to define flexibility solely as "the use of non-Microsoft tools" while casting aside exactly what OLE does for non-technical users is pretty transparent.
There's little notional difference between embedding one software tool within another, and calling one from another.
There's a considerably simpler architectural structure for the latter.
You still need the full multi-application support available. We're doing that today with browsers (the universal document reader) and plug-ins. Which are generally being considered a Bad Idea, and functionality (e.g., PDF readers, video) now being natively supplied.
I'm defining flexibility as a lack of arbitrarily-imposed constraints. Which is what the text on lock-in I referred to discusses at length.
I'm well aware that simple and expedient solutions often end up being long-term untenable. This doesn't mean that they're not simple and expedient in the first place. Though that simplicity often comes from the capacity to impose a single standard across an internally consistent (at least on a point-in-time basis) architecture.
Information technology vendors have long exploited the matter of standards to self-serving benefit. Microsoft were not consistent in either supporting or opposing standards. They were consistent in applying standards policies to their own benefit. Promotion of the IBM-PC compatibility standard increased the platform for Microsoft OS and applications sales. Hindering standards such as Ethernet, Internet, HTML, office application formats, Silverlight, OLE, AD, Exchange connectors (POP, IMAP), etc., was also strategically pursued.
You're focusing on the software specifics rather than the strategy. Yes, the trees are lovely, but there's a forest you might care to observe.
