The Scream Test: If you see something and you don't know what it does, remove it and see if anyone screams.
Chesterton's Fence [0]: "reforms should not be made until the reasoning behind the existing state of affairs is understood" (Though the purpose of this fence is not obvious, there may be valid reasons for its presence.)
[0] https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
Spoken like someone who works on pure software, with Undo!
Out in the physical world, the screaming would be followed by a loud crash. You don't touch anything if you don't know what it does. That's how equipment is destroyed, and people die.
Option one assumes that you can easily reverse your action with no damage done, which very often isn't the case
If you applied the "Scream" test for a component you don't know what it does in an airplane, it might fall/explode/whatever.
If you do it in a non-critical codebase, it might just break the build, and have someone call you for it.
In the first case, the Chesterton's fence caution is more advisable. In the second, you could go with a "remove it and see what happens" approach.
If the risk is low it may be simpler/quicker/more cost effective to turn it off and see if anyone screams. So long as you are listening for the scream and can easily turn it back on. Obviously this can be abused but there are times when it is useful.
If the risk is high, definitely spend the time to understand why, even if it is non-obvious.
But when asking the users you rarely get told to go ahead with removal.
I imagine that none of the people criticizing the idea worked for long on any large organization.
Or what they worked on was too important for this risk to be taken. In my case, people could have literally screamed.