Code quality is a side-effect of caring. The most important part of product design is caring at all levels. However it's caring about the external details that is the most important. Coding language is largely a function of the population of good coders in your areas. Code evolvability is almost entirely subjective.
Let's take two code bases. A 40 year old legacy Cobol monstrosity being maintained by a staff of well trained engineers that are engaged. The second an idiomatic Haskell application written simply and to the highest standards, but with a staff of junior engineers that specialize in imperative programming. The Cobol code base is much more evolvable. The staff can effectively make changes because they deeply know the product.
Evolvability is not an intrinsic feature of the software. It is a synthesis of culture, talent, passion, and code style.
I see where you're coming from. I totally agree that how easy it is for a company to change a codebase depends on the talent it has. But i think you can separate the entire codebase+ecosystem+team codebase from the quality of the codebase itself.
To use a simple analogy: you could argue that a modern Macbook is easier to maintain than an old Dell desktop, if the Macbook is owned by a certified Apple technician who knows how to microsolder, and the old Dell desktop is owned by someone who doesn't know how to use a screwdriver. But that doesn't change that, to change a hard drive, one needs much more skill and fancier tools than the other.
