This article misses the point about DRY. It isn’t about anticipating future uses but eliminating redundant code. The goal of the elimination is to reduce bugs. Once a function, for example, is working correctly it works all the places it is used.

If you need to rename it your tools should provide that refactoring capability. It they don’t, then get better tools. (Yes, it is a poor craftsman who blames their tools but using a hammer to drive in screws is not blaming the tool.)

A valid point raised later is you don’t know what is good in a program until you’ve gotten well into its development. Every program is a research project. Only after you’ve worked the problem for awhile do you understand the best abstractions and techniques. Here again the proper tools for refactoring are needed.