The counter to that statement is that architects learn new things too. There are always ways to improve on things from the macro level to the micro level. You'll probably find 10x more people talk about micro services than people who have actually implemented micro services at a large scale. That 90%, of which I am a part of, have a lot left to learn. And those in the 10% have probably thought of different ways of how to improve on what they've built.
I've seen many devs who have fallen into a tech debt hole by getting swept up in a language or framework.
Take for example ASP.NET. Came out around 2002. First choice is VB.NET or C#. It didn't take an expert to read the community and choose C#. At the time, it only had the Web Forms front end framework, which is and was terrible. But when you stripped away the abstractions and focused on handlers/modules, you could have had up to 15 years before .NET Core comes along and you need to migrate to Web API. The migration is a trivial replacement of wrapper code.
Something a bit more difficult- 2003. You're presented with YUI, jQuery and MooTools that are each offering overlapping promises. It takes some hands on use of each, but experience would tell you the jQuery is your ticket. Could still be sticking with it today, although it has been less useful since browsers became more standard. Thankfully it isn't entirely monolithic, the UI library is separate and they have slim versions. Should a dev want to remove the dependency it is at least a step-down process.
Something more recent (I'll probably regret discussing) is the Angular/React/Vue/whatever else argument. Angular is like choosing ASP.NET Web Forms in 2002 and is a rewrite waiting to happen. React has its good and bad parts. The correct choice for cheap tech debt is to not use a framework and instead choose libraries wisely and implement with caution.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.