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.