I didn't know that the author was on the Excel team, but it doesn't really change my feelings.

I'd say that they were the right thing to do at the time, but in the long-term they turned out to be less than ideal.

From Microsoft's perspective, the formats allowed them to be faster than the alternatives, seemed easy to maintain internally from the sound of it, and they were able to cut and run from the format when needed.

If they decided to go with a format that would be "good" for the next 30 years, would they have been as competitive back then?

As with many things, time has a way of changing our perspectives. No, Office formats would not have been competitive on earlier machines if they used a lexer/parser. Office documents weren't really documents in as much that they were memory snapshots. This is why early Office products had such high productivity over other competitive formats. If they were being written by scratch today, the formats would be very different, but then they wouldn't be as feature rich as their predecessors.

One thing overlooked is that the transition to the new DOCX formats (and PPTX, XSLX, etc.) was that they were being written about the same time Windows was working on Longhorn. Longhorn featured WinFS. WinFS would open the XML document formats and save assets like embedded images as their own components in the filesystem and then would reassemble the documents as you moved them from a WinFS store back to a traditional filesystem. The XML formats were in a similar way designed to make that process fast, just as the binary images did for earlier versions of Windows. The XML document formats were designed to integrate with a filesystem which never shipped. Without WinFS, the formats weren't built for third party interoperability, but were designed to make it easy to decompose a document into block components which the Office apps otherwise handled like verbose but compressed binary formats. If WinFS had shipped, the OOXML formats might not seem as convoluted.

"the right ones"...what would the "rights ones" have been besides shipping functioning software for their users and making money for their shareholders?

Functioning and right are not the same thing. And right for the shareholders is a strange way of defining what's right. Strange for me anyway.

That's kind of my point. On this forum we tend to define "right" by a certain standard of engineering aesthetics. I say a certain standard of aesthetics because it definitely isn't the only one.

Other definitions of "right" could reasonably include "our software performed the intended functions expected by the people that paid for it."

One common definition of "right" in capitalist countries is the fiduciary responsibility to maximize profit. It's not one that I personally think works in every scenario. That version of "right" can often find it's self in direct contradiction of definitions from moral, social, and legal areas.

My only point was that "right" means a very particular thing on HN. It means Unix-y...but not actually Unix...its this Unix that inhabits someone's mind. Where X and sockets are also "files" and text is the only RPC system you would ever need. It's also functional programming fetishistic. LISP because of the great PG. Erlang because I heard of this one really awesome app with great up time...and have you heard about Plan 9, it's perfect if it weren't for {insert dark force of mediocracy} that kept it from being a winner.

Thanks for asking. I've been needing to say that to someone for a long time.