I hope this being on HN doesn’t make more people believe that communicating like this is a good way to get attention.
If the feature uses shared internal apis, then that code has to be refactored if you need to make changes to those apis. If you need to update versions of dependencies, then the feature needs to be updated too.
If there are bugs, at a minimum you have to do something with the bug reports for those features. Even ignoring the report has overhead in the form of extra bug reports that you never intend to fix. Marking them as "won't fix" means you have to figure out a solution for dealing with the backlash from the reporter.
Then you get to the PRs from people who want to improve the feature but don't know the project well enough to really be of help. You have to either reject the PRs outright or carefully walk them through how to make them acceptable.
The minimal-work way to keep a feature around is to ignore all PRs and all bug reports for that feature. Any other approach is extra overhead. But taking that approach is still in many ways worse than stripping the feature out entirely, because you're left with a feature that only sort of works some of the time, it makes your code more resistant to change than if it were gone, and you're building up a backlog of reports and PRs you never intend to fix.
Removing a feature might be a bit of work now, but if it avoids hours of headaches later, that's absolutely worth it.
One literally could not pick up a better example of something going in the wrong direction that simply accumulates more tech debt.
I mean, people have called the GNOME team everything else, maybe it'll take stronger words to get a message across?