I worked at Microsoft too, in one of the best divisions full of the smartest developers in the world. I worked with some truly amazing individuals, some outright geniuses in their field, in fact. Some of the lessons I learned from my coworkers while I was there I still carry with me and value very heavily. But I wouldn't say I was awed as the author was. Nor was it my experience that there was a distinct lack of clueless people. I interacted with a number of folks that didn't have what I would consider a full toolkit of talent, skills, experience, and judgment (maybe my standards are higher than the author's, I don't know).

I'd say the problems that exist in that environment and in that group of people (and other similar groups at dev shops all around the world) go well beyond the ability to rationalize anything. The biggest problem I've experienced consistently, everywhere, is a lack of caring about the right things. A lot of engineers live in a little fantasy bubble divorced from the real world. Separated from the consequences of their actions, separated from a connection with the actual practical use of their product by real humans. They too often don't have an understanding of how what they're working on fits into the "real world" and instead just enjoy twiddling the knobs and levers behind the scenes because that's a fun hobby for them.

A big problem I've seen consistently is the willingness to accept the status quo regardless of the way it is because it "works". And this is one case where being "smart" and capable can actually be a detriment. Being smart and capable means that you can take an incredibly broken tool or process and still make productive use out of it. And to some extent there's a pride or a bravado that comes from doing so (relevant xkcd: https://xkcd.com/378/). But that sort of thing is self-defeating. It doesn't matter that you can get by with horrible internal tools, because in reality existing in that state destroys an enormous amount of productivity. Programmers too easily fall into the trap of thinking that the hard way is the better way, and you see this in code too where devs think they're smart by writing complicated "sophisticated" code for no good reason when plain old run of the mill highly readable code would be vastly preferred.

As the author touches on the curse of excessive confidence is also a big problem. You see a lot of developers who fall into the know-it-all trap and think that because they completed a challenging degree program, work in a highly paid highly impactful field, and have some degree of expertise in some tiny corner of that field that somehow that makes them einsteins or something. The reality is that no matter how much you as an individual can possibly know your ignorance will always outweigh your knowledge by huge orders of magnitude, even within a given field. A big problem this causes is developers not realizing their limitations in certain areas and just papering over those problems, perhaps even thinking that they are fundamental to the discipline or the field in general. I've seen countless examples of systems put together by very smart very competent devs who had some significant gap in their overall skillset and instead of seeking outside help or advice or taking the time to learn something new they instead just came up with some horrible hack rooted in stuff they were comfortable with but applied in a totally inappropriate manner. And those hacks are often so deep into the system that it takes a ton of work to refactor them out and away, on top of all the problems caused by the system being fundamentally flawed in design. Whereas spending just a few days or a week of time learning something new could have resulted in a much more robust system from the outset, if they'd simply have checked their confidence a bit.