I'm not so sure that this would work. The goal of your employer is to keep you working.
If the workforce participates to much, you could run into the Tesla problem, a.k.a. your early employees become millionaires and stop working (in case of Tesla because of company stocks).
I explicitly mentioned profit sharing because that is different from simply owning stock in your company. Owning stock / options, although better than nothing, is not a meaningful incentive for most as the value of it is generally so far removed from your individual labor unless your company is just a handful of people (at which point your equity is useless unless there's a liquidation event in the future, which your employers can rob you of anytime by firing you before they vest or diluting it through further fundraising).
By profit sharing, I mean literally giving workers a cut of their direct contributions. This is how sales people get paid, and most sales people won't quit after making a few million if they can continue to make more millions in the same fashion by being directly compensated for the money they bring in. This is not analogous to a Tesla engineer in a massive corporation with thousand of employees finally getting exit liquidity on their stock options.
Of course it's harder to measure direct contribution of an engineer compared to a sales person, but I don't think that difficulty means that it's not worth trying. Of course for this to actually happen, employers would have to start trying this out and proving its success - which may be a tall order in a job market where employers already wield such enormous power.
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.