Just watchted this rant and as I listen, certain obvious facts became clear to me that Casey is completely missing:
1) It's pretty obvious why Microsoft cares little about the load-time of VS. Their main clientell tend to just have the thing open all the time. They don't open it many times per-hour, just for debugging. It's a heavy-duty IDE, not a text editor.
So that workflow is just not on their radar as something to be concearned about - at all.
2) Software has a maturation cycle, it peaks at some point and then gradually deteriorates. It's a bell curve.
That is ESPECIALLY true for any long-lived commercial software. Just take any software that you can think of that had existed for over a decade, and you'll see that dynamic at play.
The reasons for that have nothing at all to do with developer competence.
The main reasons are economic, and psycho-social.
The economic reason is akin to "planned-obselecense" in consumer electronics:
They can't just develop something to perfection, and then just continue selling the exact same thing every year, because consumers will then have no reason to ever upgrade. With consumer electronics they can time some components to fail after some period of time. But software doesn't deteriorate if you just keep using it without change.
So unless you do something nepherious, the only way to get people to upgrade is to add more features all the time - even when they are completely unncessary, or are relevant to very few people.
That's why commercial software gets bloated over time.
To some extent, open source software suffers much less from this, as it can affort to stop evolving once it's reached some zenith point, doing what it needs to do well - and without any negative economic consequences.
The psycho-social reason has to do with scale:
The bigger a project gets and the more people are involved, the more likely it gets that the product will get worst over time. That's true about any kind of large scale project, and is not even specific to software.
The project accrudes more varying oppinions over time and so more likelyhood for conflicting ones, pushing the project internally into different directions at the same time. The larger any group of people get, the more politics there will be. It's inevitable.
Take the case of C++ as an example: "Design by Comitty".
Now contrast that with what J.B is doing:
Even within a single person's mind, there will inevitably be contradictions and competing interests, and more and more of those as a project grows and expands. Because there more variables there are, the higher is the likelyhood for conflict. That's just basic combinatorial logic.
Contradictions are far more likely to be resolved within the privacy of a single person's mind then within a group of people, and the larger the group the lower the likelyhood.
So the more people are involved in a project, the higher the likelyhood for more internal contradictions in it.
That's a major contributer to incidental complexity.
I can go on about the accrusion of technical debt, the explosion of "special-cases" as a project accrudes more features, the necessity for backwards-compatibility, etc, etc.
But really, these are some clear reasons, none of which have anything to do with developer competence.