The other side of this is that you were getting requests for those settings, users wanted to be able to set them. Agreed that discoverability was a problem, but behind the discoverability, people wanted the ability to define custom behaviors or change default behaviors. I think you sum it up perfectly with:
> If you can do the right thing automatically
I think a lot of software will shoot for doing the right thing automatically when they don't actually know what the right thing is. Or they'll remove the options because they think that the users don't want settings at all. But users do often want all of the behaviors (even the contradictory behaviors) that settings enable -- they just also want those settings to be discoverable and intuitive, and ideally they don't want to think about what they're set to most of the time.
As an analogy, as a user I like automatic high beams in my car if they work well. And having an automatic mode that's turned on by default might mean that I don't need to spend as much time messing with my high-beam brightness, and that's great. In a world where they worked perfectly, I might never even need to learn how to adjust the beam brightness myself. But I still want the behavior of different beam brightness in different contexts.
There's a trap designers fall into sometimes where they say, "settings are too hard for users, therefore the headlights should only have one brightness." If a bunch of users are asking you about something, that means they're engaged with and care about the functionality they're asking about. It might of course indicate that different defaults should be set, or that UI should be reorganized. And if you can do the right thing automatically, then you might be able to get rid of a lot of those support calls by doing that instead. But make sure you actually can first, because users are signaling with those support calls that they do care about that feature/behavior.