People often try to implement things with a hypothetical future use in mind. It may even be a realistic future, but it is never the less a future that does not need to be dealt with right now. Adding code for things that aren't actually in play means adding something you can't actually test. It means people may abuse what you set up later (and introduce bugs) if the actual future turns out different than you planned. Taken to the extreme, this planning for the future turns one into an architecture astronaut.
In my experience this is often possible by removing duplicated functionality into a shared implementation. That is by exchanging multiple features of linear complexity into a single implementation. Due to being shared, that implementation will tend to have geometric complexity.
That means the duplication has to be highly significant and variations need to be few for it to pay off. ... And you'll better hope you have a good set of tests to verify everything is still working.
In most cases it's still a good idea, but it's still a case where you need to argue that you really need it, so it's no exeption at all.
It's a more fleshed out version of YAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it; that page has a number of other similar acronyms; if it ain't broke, don't fix it, KISS, feature creep; all names for the same problem.
Mind you, software developers aren't the only ones that cause this; a product owner / lead / whoever calls the shots is also very likely to keep bolting features onto a product. Either they have to keep that impulse down, or they too need a system to manage it. Also they shouldn't be afraid of culling existing features; what usually seems to happen is that more and more stuff is bolted on, until it's too much and they just rewrite the whole thing from scratch, leading to a clean, lean new application - often missing some features that older users like. Either they do it, or a competitor does.
My experience is that it is very hard to cull features, even with a sympathetic product manager. Sales wants to have as many boxes ticked as possible, so they fight tooth and nail against feature removal, all the while forgetting that simplicity is a feature too.
As I've gotten older I've seen the value of this rule. Though it sounds merely negative, it can produce effects that seem little short of genius.