1. The article derides those using "years of experience as some sort of a badge of knowledge", yet keeps on referring to "experienced" programmers as if they were better. Maybe it's terminology, but in my experience (no pun intended) there's no useful correlation between the time one is writing software and their ability to tackle hard problems. "Experience" seem to matter much less than talent, imagination and passion.
2. Article says "Sitting in an office and shuffling papers around for a decade doesn’t make you a master programmer. Writing software does." -- writing software for a decade really doesn't automatically make somebody a master programmer. The author states elsewhere in the article: "I believe your self interest and curiosity matter more than the years spent writing getters and setters". So, which one is true? As mentioned in the previous point, I tend to think the latter.
3. The article mentions "the vast majority of software is written by the ones who are still learning the ropes" as if it were a bad thing. It really isn't, in fact this is the only way people can get "experience" in a growing industry where junior devs outnumber senior devs simply due to how large the industry has grown over the past ~40 years. It has everything to do with exponential growth in the software industry and has nothing to do with programmers going into middle management and leadership roles.
4. To make sure software is competently written even if most of them are written by junior devs, the managers/leads have to make sure everybody is assigned tasks that they can handle, perhaps with supervision by a more senior/skilled dev. The job for the tech lead is to figure out which is which, and ensure that the critical parts are competently dealt with by appropriately skilled people. This is a skill that requires competence and experience. Unless you have an endless supply of senior devs, you definitely want to "distract" the senior developers from their implementation work and put them in charge of this work.
5. Article says "the experienced programmers will take care of the design problems, but that is not going to save your bacon if the implementation of a great design is terrible." -- this is of course true if you have a team of truly terrible programmers, but not necessarily true if they are just "mediocre". Design decisions include choice of language and architecture (and sometimes process), and some demand more of the developers than others. There are ways to isolate bad implementation with clean(ish) interfaces, so that "big ball of complicated code" becomes small balls of bad code that can be fixed up bit by bit.
6. This is one of the most confused claims in the article: "If you want to produce a high quality software, you also need enough experienced people in the trenches that are not merely delegating the orders from the ivory tower." The only way this can work is if you only hire "experienced" people and reject all junior devs. Because in the author's ideal world there's really no place for junior devs. They can't be mentored because that will distract "experienced programmers" from the real work in the trenches. They can't be groomed for management roles because then they can't become "experienced programmers". It really sounds like to me that the author doesn't really know how to properly manage junior devs in a team and simply assumes that if "experienced programmers" who have kept writing software in the trenches were able to keep writing software, then the result would automagically not suck. I don't think the real world works that way, not until the software industry collapses and only the best programmers are able to keep being employed.
In all it feels like the author was trying to sound insightful by stringing together a story that, at best, is just pointing out that "experienced programmers" are better than "wet behind the ears" without providing a suggested solution, and at worst, making up superficial narratives that doesn't really hold up when you try to poke it.
Sure, for every senior dev taking on management or mentoring duties, the team loses out some quality man-hours on coding, but that is presumably a positive trade overall, or people would stop doing that. The only way to keep "experienced programmers" focused on coding are: don't hire junior devs, don't mentor junior devs and don't let technical staff enter management. I'm pretty sure that's not what the author tried to say, and unless I'm missing some obvious solution pointed out somewhere, the whole point of the article seems to be spinning a flamewar from github into a sentimental narrative that doesn't lead to any conclusions..