Every configuration option is a feature you have to test, document, and support forever.
I learned this on a project where we added an adapter pattern early so we could swap out the backend later. Three years in, we had never swapped the backend. We had spent a lot of time maintaining the adapter interface and writing shims as the real backend changed in ways the abstraction did not expect.
The option cost more than it saved.
The pattern I have noticed: engineers add optionality as a hedge against uncertainty. We do not know exactly what we will need, so we build something flexible. But flexibility is not free. Every config knob creates another state to test and another path for the next reader to understand.
The useful question is not “could this need to change?” Everything could. The question is “how hard would this be to change later?” Often the answer is: not very hard. Find the one place, change it, ship it. The abstraction would have cost more.
Simple things are easier to change than flexible things. A direct database call is easier to replace than a repository pattern with five implementations. A hardcoded value is easier to parameterize than a config system with a dozen keys.
When in doubt, do the simple thing. Leave the option until you actually need it.