Still, apply common sense. Sometimes the probability of adding something is so high and the cost of making an extension point so low that it makes sense to design with extensibility in mind. These extension points are rare, though, and usually occur at major module boundaries (e.g., plugins), and don't need to be scattered through random bits of your code.

You also have to factor in the cost to maintain your extension which you currently have no use for, which most people forget.

It also might be easy to include now, but your extension might complicate a new feature request. Or the new feature might complicate your previously simple extension. If it's still unused, don't be afraid to throw it away then either.

I find that unneeded functionality also complicates refactoring efforts.

Still, why not wait to add it?

Because sometimes those choices have a large effect on the amount of work/mental tax in the future - for example, if you know that a new feature will have to interop with yours in the near future and the cost is low to implement the right extensibility point now, it would be absolutely stupid not to - I would call that bad engineering that costs time & effort.

Obviously one doesn't want to go down the rabbit hole too early, but the other extreme is just as bad.

Waiting is good when the cost model for the added code is much more in focus later.

The cost to add it is often much higher, once the code has high fan in (lots of code paths depend on it).

I am definitely a fan of not over engineering, but I'm more of a fan of thinking. Think about your problem and your use cases, and about your own ability to predict the future. If you can predict future changes with high probability, then go ahead and design for those. If you're not a domain expert, you probably can't predict the future at all (and you probably grossly underestimate how bad your predictions are), so you should stick to the bare minimum.

It's a slippery slope.