When removing a feature, you have to understand all the real world use-cases, before you can kill it. This is a lot of work, therefor it is much easier to not touch it and work on the next feature.
A lot of this comes down to shifting the burden within responsibilities of the team. Product management having a good understanding of the hidden use cases is ideal, but really hard. Not doing that means you have Development and QA spending time on stuff no one uses.
One of the interesting outcomes is when you accidentally break a feature. If someone complains at least you know it's being used, and ideally PM starts a discussion on the real use case. My favorite is noticing something is broken while working on adjacent code, and looking at git blame to see it's been broken for months. In theory at least, that should be an easy decision to kill it; in practice my experience is everyone is always very hesitant to actually do that.
It can be acceptable to un-ship a feature, breaking users' flows -- as long as there are other means that are left for them to accomplish the same result with just as much effort.
Even then, people having to re-train themselves is not a good thing, but at the very least it should still be possible to get the same result.
In our case, the way the users (ab)used the old implementation allowed them to do something that was not easily done by other means.
So we simply flipped the switch back, enabling the old behavior.
I really hope that the developers elsewhere would do the same in a similar scenario for products that I use.