This article is at best half useful, and missing the other half is potentially quite dangerous (to organizations, to people's careers, etc.) What's missing is a discussion of power and power dynamics (and healthy vs. unhealthy versions of same, let alone how to work effectively in either or drive change). Partly this comes down to a failure on the author's part to care about power dynamics or look at their own power. In this case the author was able to just blindly drive change by charging in like a bull in a china shop and the only consequence to themselves was a very minor verbal admonition, that's an indication of their level of power and where they sit in the overall power structure of their org, not every dev. in a similar position would see the same results, however. Many people would have to navigate that problem much more cautiously to avoid becoming fired or ostracized.

(Edit: and indeed I see another comment in this thread about someone who did exactly the same thing as the article's author and it turned out very poorly for them because they lacked the power the author has/had.)

Additionally, the author completely ignores the value of "soft skills" and implies that all that's necessary to have a positive impact where you work is to blindly seek the technologically superior choice whenever possible, ignoring politics, power, and ego (yours and others) along the way. There's value to that, but there's also great potential for that sort of mindset to lead you astray, because it's often difficult to know "what's best" in every situation. In the article's example the pros and cons were fairly straightforward, but most of the time the situation is likely to be a lot more complex or a lot more subtle. And it may be easy to make the wrong value judgment (and consequently fight the wrong technical fight) based on ignorance.

On top of that, this story is very frustrating because it only concerns itself with technical problems. At the end of the day the organization was still just as dysfunctional as ever even though it grudgingly fixed a technical problem it found it couldn't ignore. The author helped fixed a defect in code but they did almost nothing to help fix a much larger and more serious defect in the organization they worked in.