Another way of looking at this argument is that the majority of hard problems in software engineering aren't computer science problems, they're people managemen

Another way of looking at this argument is that the majority of hard problems in software engineering aren't computer science problems, they're people management problems. It's not merely enough to create a programming language with an order-of-magnitude improvement in productivity, you also need to convince all the stakeholders to let the project be developed in that programming language, which includes both helping them get over their unfounded fears ("it won't work") and doing the technical work (or the recursive people work) to get them over their well-founded fears ("how will we hire/train programmers," "what do we do with all our existing code in this other language," "is there a vibrant language ecosystem," "where's the development tooling," etc.). Same applies to other sorts of possible silver bullets. The Linux kernel has been using git for well over a decade, but even GCC (a free software project which has no managers adding requirements to make themselves look good) only switched to git last week. In other words, if you have a 10x technical silver bullet against accidental complexity, it won't look like a silver bullet / it'll appear to get stopped at essential complexity until you do the people work too. Without that, you won't be able to point at very many projects that have actually seen the 10x improvement.