That to me sounds like a bad incentive in engineering. Everybody wants to work only on new features, things like code quality, maintenance, refactoring, infrastructure don't matter anymore.
For tasks that aren't straightforward to measure impact on bottom line, perhaps their impact can be approximated via product owners setting bounties on them.
In any case as important as things like code quality are, they are ancillary to the bottom line of a business. Employers hire employees to increase the profitability of their business, and code quality is not the top priority.
The value of that is being distributed in very small increments over the whole dev team in the span of years. It's impossible to measure.
> Infrastructure updates can directly reduce server costs, latency, or have other benefits.
Well, most of the work is in that "other benefits". Very difficult to measure.
> Employers hire employees to increase the profitability of their business, and code quality is not the top priority.
With your incentive model it has 0 priority and the project will die under the weight of technical debt, inability to add features in reasonable time and critical defects appearing out of the blue.
This is just factually incorrect as I've already explained, such as via the ability to provide bounties on technical debt reduction. Also an incentive doesn't mean that one has to chase that incentive, or that all work must revolve around those incentives.
In any case, it's already the situation at most companies that they tend to prioritize shipping new features and bug fixes above code refactoring. As a developer myself, I'm simply suggesting a way in which employers can further motivate employees and promote intrapraneurship by more directly compensation employees for their contributions. If you're happy with the status quo, all the power to you.