Depends on which meaure of good in use obviously, but I have never seen anyone capable of being efficient over significant time spans without in some way having

Depends on which meaure of good in use obviously, but I have never seen anyone capable of being efficient over significant time spans without in some way having design and architecture be guided by principles that balance cost of change, cost of implementation, and difficulty of understanding. Ignoring cost of change can be absolutely devastating in the long run, but believing you can somehow scry the future for all possible extension points necessary is equally so. Designing for (anticipated) change in my mind is not at all about adding hooks, API's, or any code at all for that matter. I think of it more like making sure your system respect analogues to gravity and the other natural laws as best translated into the more abstract relations relevant for the particular kind of system you are building. One could call it programmer and refactoring friendly design and not miss the target by much.