Ye... No. Note that your made-up productivity algebra model crumbles as soon as you stop seeing developers as code churning machine and instead as what they should be, problem solvers. That's because quantity is not the only metric by which you can measure problems. Complexity and ease are others. A dozen average problems do not necessarily equate a single hard one. Hard problems can prove elusive to average devs and they're usually where you see materialize the limitations of the thinking that a single great developer can simply be replaced with a dozen average ones. One such manifestation is commonly called "technical debt".
Reminds me of https://youtu.be/VAAOnmOlrLU?t=155
Of course star developers hate Scrum. But star developer code is often crummy too, and technology advances so fast that I'm glad for every dollar I didn't pay for divine Win32 code.
Given the available pool of poor/average/great developers, this may be the correct decision.
Model: There are a1, a2, a3 developers of poor/average/quality. Poor developers cost p1, have a default productivity of q1. Average developers cost and produce p2, q2 and great developers cost, produce p3, q3. Scrum brings everyone's productivity to q2. Note that no one gets a raise or pay cut.
Without Scrum your total payoff is
With Scrum it becomes So what you need from Scrum to be worthwhile is that i.e. Now, let's say 60% of programmers are poor; a1/a3 is 1.5. So even if poor developers improve by 1/3 while great developers are downgraded by 1, we're better off.