The problem with building an architecture that is optimized for making certain predicted changes is that such an architecture usually makes unpredicted changes more complicated. Which is a problem because it is usually very difficult to predict if, when and how a system will be modified in the future. This applies to games in particular, where you often "find the fun" by repeatedly playtesting and iterating on your design. So your prediction on patch trends in this question could very likely turn out to be very wrong.
Far too often in my life did I design convoluted architectures that would have made certain changes really easy in the future, just for those changes to never happen. Turned out that the designers and/or users of the system had far different ideas what things they wanted to change or add. So my super-flexible-super-extensible architecture remained unchanged, while I had to do ugly workarounds and painful refactorings to fulfill requirements I had never expected.
Over time I switched to a different approach:
In the prototyping stage, I keep it simple and stupid. Often the simple solutions are the best solutions. The fewer layers of abstraction you have, the fewer layers of abstraction need to change when you figure out that your abstraction was misguided. And the fewer hours of work you end up losing when it turns out that the architecture you over-engineered actually wasn't needed at all.
So when you are just starting out, shamelessly hardcode everything. Changing the attack of the short sword from 10 to 12 requires a recompile? So what? The code-base is still small, so recompiling is quick.
When I have a difficult change, I refactor to make the difficult change easy, then make the easy change (quote from Kent Beck). The problem with most KISS architectures is that as soon as you start iterating on them, you will encounter change requests which take a lot of work at a lot of different places. This is when I start engineering abstraction layers, not before. It ensures that I don't start over-engineering before I have at least one confirmed use-case for a certain abstraction.
For example, when I discover that compilation times get longer and we keep changing weapon stats over and over again, then it might be time to move all those weapon stats to a configuration file. But the good thing is that at that point, we already have some experience with the system. I know what properties the weapons have, and I probably have a much better idea of what requirements that configuration file actually needs to fulfill. So I have far more data to make my design decisions on.