These days I am working on some 20 year old code used in a few dozen manufacturing plants around the globe; the reason I asked to be allowed to fix it and the reason my manager allowed me to do it is that we have performance issues in some of the biggest plants (by the number of production lines) and this code is part of the problem. If that would not be the case, that code would continue to run as is for another 10 years.
Code modernization in some circumstances does not bring business value. In the plants we have some hardware that is decades old and it works as well as the one built last year, more modern software would bring no difference as physical limits (ex: how many bottles you can fill on a line) makes a line capable to run on a smartphone with MS-DOS and Turbo Pascal on it (we don't use that, of course). If it runs and you cannot improve it more than the cost of the improvement, leave it as is.
In some cases it does make sense (imagine something like Voyagers for instance where you simply can't change things even if you wanted to), but in most cases it doesn't.
... as is the company. This has Unicorn Project written all over it.
Very dumb response to the code modernization work. Just because it's not a product feature, it absolutely doesn't mean it has no business value.
I also completely disagree that the lesson from it is saying no to such efforts. Increasing tech debt in the name of "more business value" is the worst idea any team can have.
If team leadership sees no value in such work, the team is set to fail.