Adding a configuration option is the easiest way to end a disagreement. One team wants the behaviour, another does not, and a setting satisfies both without anyone having to decide.
The cost arrives later, spread thinly across every future change, which is why it is almost never attributed to the decision that caused it.
Options multiply, they do not add
Ten independent boolean settings describe more than a thousand possible configurations. You will test a handful of them. Customers will run the rest.
This is why bugs in configurable software so often appear impossible to reproduce: the reporter is in a state nobody has ever assembled deliberately.
They are effectively permanent
Once a setting exists and anyone has changed it from the default, removing it is a breaking change. In practice options accumulate for the life of the product, including the ones added for a customer who left years ago.
Deprecating configuration is possible but rarely prioritised, because each individual option seems too small to justify the conversation.
They usually signal an unmade decision
A setting introduced because the team could not agree on the right behaviour has not resolved anything. It has transferred the decision to every user, most of whom have less context than the team did.
Users generally want good defaults, not choices. A product that asks its users to make its design decisions is offloading work rather than providing flexibility.
When a setting is genuinely right
Where different users have genuinely incompatible needs, where the correct value depends on the environment, or where a regulatory difference is real. In those cases a setting is the honest answer.
The test is whether you can name two specific users who need different values and explain why neither could adapt.
Prefer deciding well over deciding twice. Where you must add an option, document why it exists — otherwise nobody will ever be able to justify removing it.