Your calculation doesn't take into account the time savings for brand new users. Since they don't have to unlearn anything, they start saving the time immediately.
Not saying it is right or wrong, but a lot of the upsetting changes for existing users are for the benefit of new users.
We can start with the contention that that isn't true. Even for a new user, the change is going to bring with it a bunch of new bugs because the new code is new, and invalidate all of the solutions to problems that people can search for on the internet until the new thing is as old as the old thing (at which point somebody tries to replace it again).
Also, "users" are "people" and the average adult lifespan (18-78) is around 60 years. That implies that the time for the "new users" to become half of the user base is around 30 years, so what does that say about how often it makes sense to do this?
But suppose you're right. Then the solution is competition. Don't take away the old thing, provide both. If the new users want to use the new thing and the old users want to use the old thing, great.
And then if the new users still want to use the old thing you've got a pretty good red flag that you messed it up.
But the real situation is even stronger to my point, because most software in use today won't be in 30 years. So the real graph for established products is that you continue to get new users for five or ten years as young people learn and old people die, but never enough to even hit the halfway mark. Then your company folds or gets out-competed by something else, your user base falls off a cliff and the software becomes irrelevant.
The point at which "new users" are the majority of the user base never even happens.
> And then if the new users still want to use the old thing you've got a pretty good red flag that you messed it up.
Your new UI might be garbage, but there's no red flag here. A new user will likely need to make use of tutorials, troubleshooting, and other help online; most or all of which will be based on your old UI (and possibly coupled with comments like, 'Don't use the new UI, it's trash. Here is how to switch...'). Having been such a new user, I only pick the new UI when forced or when it's clearly better; the former being the more common case.
Sure, you can make your official documentation use the correct UI (or design your UI in such a way that the documentation can be agnostic—but then what is this big change that makes lives better?), but unless your documentation is very good, people are still going to need to reference all these other sources.
Not saying it is right or wrong, but a lot of the upsetting changes for existing users are for the benefit of new users.