As you add more settings you increase the number of possible code paths and places for bugs to hide exponentially. It’s all too easy to add a setting due to uncertainty about what the right choice is and that’s really bad. If you’re sure that the setting is because of genuinely divergent use cases (and that you genuinely want to support both use cases) then maybe it’s ok to add the setting. My rule of thumb is to wait for a user to make an impassioned argument for their use case. Never add a setting speculatively, i.e., by imagining what a user will want. Default to total paternalism where you decide what the user wants.
Also things like documentation are easier the fewer settings there are. Also the fact that if you add a setting that turns out to be stupid, someone will get attached to it and it will be a big ordeal to get rid of it.
Beeminder internal case study: https://github.com/beeminder/beeminder/issues/520