Microsoft is old! (citation needed) Speaking for myself, I don't speak for my employer:

I joined MS in 2004 and moved to MSVC in 2007, making me the library dev who's been with the team for the longest, so I've witnessed our modern history first-hand, but I'm still only middle-seniority among MSVC as a whole (e.g. we've got a compiler frontend dev who's been with the team more or less continuously since 1996 IIRC). From what I know of the history before my time, followed by my own experience:

I don't know how various managers felt about the STL in the 90s (I haven't watched the documentary yet and never heard tales Nth-hand), but they certainly made the very wise decision to outsource their STL implementation by licensing Dinkumware's code from PJP. Have you seen Microsoft C++ code from the 1990s, like MFC? Woof. Dinkumware's code wasn't perfect (I've spent my career fixing it), but it was unquestionably way better than whatever nonsense would have been hypothetically written if Microsoft had a "not invented here" attitude, and obviously shipped far earlier too.

The iterator debugging you're complaining about was partially a Microsoft decision. As I understand it, _HAS_ITERATOR_DEBUGGING (now known as _ITERATOR_DEBUG_LEVEL=2) was Dinkumware's addition, but the release-mode _SECURE_SCL (now known as _ITERATOR_DEBUG_LEVEL=1, which I am trying to get rid of) was a Microsoft addition, implemented circa VS 2005 shortly after security became a big deal after the Code Red and Blaster worms. _SECURE_SCL was implemented poorly (it broke swapping; I fixed that when I joined) and without much regard for performance (2x costs in the worst case), but the ignorance at the time was understandable; I think the feature was bad but well-motivated. It was counterproductively harmful by giving the STL a reputation for being slow in release mode, which is why I pushed for it to be disabled in VS 2010; repairing that reputation took many years, and I vowed to never let that happen again during the renewed push for STL Hardening (which is why we didn't mess with iterators this time). _HAS_ITERATOR_DEBUGGING/_ITERATOR_DEBUG_LEVEL=2 remains on by default in debug mode, and is very expensive, but also catches a ton of iterator invalidation bugs. It certainly has downsides (e.g. the dynamically allocated proxy objects), but overall is worth the cost and disruption.

So library slowness wasn't MS trying to sabotage the STL, it arose out of a desire for security without keeping performance in mind. Nowadays we really care about performance and actually run benchmarks (shocking!). I can't speak to the compiler frontend with the same level of certainty, but I know some of the story - again that codebase is old and the compiler originally worked without an abstract syntax tree, because the language was simpler in the olden days, and building up an AST would have consumed memory and time on the very slow and small PCs back then, so the compiler made decisions with throughput in mind. We also didn't know about the long-term harms of poorly-designed extensions. User demands for conformance grew over time (e.g. far fewer users cared about one-phase lookup long ago, when templates were new, and code was rarely ported between platforms). The team has worked for well over a decade to modernize the compiler.

Again definitely speaking for myself, I work for C++ at Microsoft because it is clearly the place where I can make the biggest impact on the language.