Users experience feature removal as arbitrary loss. From the maintaining side it is a cost decision, because every feature that exists must keep being paid for.
Features have a running cost
A shipped feature must be tested on every release, kept working as underlying platforms change, documented, and supported when users have questions about it.
That cost recurs indefinitely and does not depend on how many people use the feature. A rarely-used option consumes similar maintenance effort to a popular one.
The total across a mature product becomes large enough that it constrains what else can be built, which is when removal starts being considered seriously.
Old features constrain new ones
Every feature makes assumptions about data structures, interfaces and behaviour. Changing anything underneath requires either preserving those assumptions or reworking the feature.
A rarely-used capability that blocks a redesign is therefore more expensive than its usage suggests, because it is charging the cost of the change it prevents.
This is why removals often cluster around major architectural work rather than arriving steadily. The rewrite is what forces the accounting.
Usage data drives the decision imperfectly
Teams measure how many users touch a feature, but raw counts hide importance. A feature used by a small number of people may be essential to their entire workflow.
Measurement also misses features used rarely but critically, such as data export or recovery tools, which show low engagement precisely because they are needed only occasionally.
Good deprecation processes look at whether an alternative exists for affected users, not only at how many there are.
Deprecation is meant to be a sequence
The intended pattern is to announce the change, provide a replacement, warn inside the product, and only then remove, with enough time for dependent work to adapt.
Skipping steps is what generates the strongest reactions, because users discover the removal at the moment they need the feature rather than in advance.
Subscription models change the calculation
Software sold once was finished at release and features persisted because there was no mechanism to remove them. Continuously delivered software has no such fixed point.
That makes ongoing curation possible, and also means users never reach a version that stays as they learned it.
The result is a permanent tension: the maintenance argument for removal is sound, and the user's expectation that a working tool keeps working is equally reasonable.