I've convinced that 95% if the "extension points" I've seen built into code over the years never get used to create extensions - usually because they have significant assumptions about what extensions would be required that turn out to be very wrong.
There are subtle ways to add extension points that most people won’t even notice.
For instance, putting related code into a data structure allows you to add more to it later without replumbing the whole system (as opposed to functions with five arguments).
With enough experience with refactoring, just choosing a structure that’s easy to refactor can serve as an extension point. (I have even tricked people into implementing a feature the way I had it in my head by writing the intermediate version in such a way to suggest a simple change for part 2.)
Never add any extension points you don't already need, but design as if you could suddenly be tasked with adding all kinds of weird ones, but mostly without spending any significant time.
Try to make sure that reasonable extensions are cheap to add, and that even some of the more unreasonable ones are at least possible without complete system redesign.
This should not significantly impact either implementation time, or design time. But it will almost certainly make you avoid some really bad design choices that make quite plausible changes extremely expensive.
Good design is more about avoiding obvious traps than finding a path to nirvana.
