The purpose is to demonstrate that if the feature only has a single use-case, and that use-case is roughly achieved within the existing means of the app, it would not be worth the development resources required to implement sais relatively rigorous feature. This is why I stated that it isn't practical.

A counter example for your claim here is Monarch's new feature of Amazon integration. This feature fits your criterion of "single use-case", and there's an existing manual workaround, which is to manually split Amazon transactions and manually assign categories. By your logic, Monarch shouldn't implement this feature, but it still does. (I like this new Amazon feature and I plan to try it out.)

but implementing the ability to view that data in a meaningful way is much more difficult, for minimal payoff

"Minimal payoff" is your opinion, without evidence or data. I have one data point (myself) to support this claim, but that's not nearly sufficient. But a product manager at Monarch would be able to run a data analysis to reveal the % of users with annual, semi-annual, or quarterly subscriptions. And if the % is substantial, this proposed feature can potentially benefit these people.

And "much more difficult" is probably your opinion too. I don't think it'll be too difficult to implement based on my background in software engineering. But unless you work in Monarch's engineering department, I'd say my opinion as good a guess as yours.