Assuming the same number of votes by the same amount of SP, each vote is allocating exactly the same as before
Your assumption is incorrect. What you want is "assuming the same number of rshares used to assign the pool" and HF20 will change that number by destroying some of them in the post payout process.
The fact that some of the rshares are destroyed after the vote doesn't really matter, they're still not being used to determine the rewards. So it's equivalent to a dramatic reduction in voting.
It's probably easier to think about this in some of the other ways "return to the pool" happens, like @steemit not voting. But it's the same effect.
Again, 1000 STEEM goes into the pool each day, which means 1000 STEEM goes out. If 1 million SP place votes, then STEEM is awarded out of the pool at a rate of 0.001 STEEM/SP. What happens in between doesn't matter.
There's no way around this.
(Obviously these numbers are made up and hypothetical. Substitute the actual numbers and the actual rate of STEEM/SP will still remain the same before and after.)
While the numbers end up the same, the calculations have different denominators, and that turns out to be pretty important.
The total Steem in the pool is determined based on the total number of Steem in existence, while the distribution of the pool is determined based on the SP used to generate rshares.
Now that SBD is closer to normal that ratio is the primary factor determining things like the self-voting APR and the total profit available in a vote-selling transaction. It's a big deal.
I'm only going to say this one more time. The reward generated per SP will be exactly the same as before The number of rshares used to calculate payout will be lower, but the reward per rshare will be higher. The two differences will exactly cancel out.
By design, authors will receive (slightly) less of that reward and curators will receive (slightly) more. Neither you nor anyone else has yet come up with a coherent explanation why this is a bad thing.