Setting the ValidatorStakeWeightMultiplier to 1 was to allow for future growth of the network if/when needed (per msa). I have posted several of his comments (which are apropos to this discussion). He had other suggestions which I think should be considered in context. Here is what he wrote (over several days and messages):
I hardly think that not recommending parameter settings is a valid reason to vote against PIP-22.
I know that adding ValidatorStakeFloorMultiplierExponent to PIP-22 (and perhaps more importantly the whole discussion of why it is beneficial to include) made PIP-22 feel “too complex” to some people . No worries. Just set it to 1.0 on day 1 so that it has no effect and worry about changing it in the future if and when it is needed. It was added because it is the only parameter that can incentivize to diversify to more nodes if that is needed for network stability and security in the future as the network grows.
My recommended Day-1 settings that would get written up and voted on in a PUP (ie turning on the incentive to consolidate) would be (15k, ==averagestakefloor , 75k, 1) . Very conservative. Allow 5x consolidation to start and defer any nonlinearity in the weighting until the future. Per discussion above, DAO would adjust the second parameter over the transition to keep up with average consolidation that takes place in response to the consolidation incentive being turned on.
To me it seems that the ones voting against PIP-22 have lost sight that by itself the proposal adds the parameters and the few lines of code that provide the knobs needed to enable varying degrees of weighed rewards while deferring to an accompanying PUP the actual setting of the parameters (i.e., whether or not to turn on the weighted staking and if so by how much). I urge remaining voters to vote to approve PIP-22 as it is rather a minimal dev effort and save the debate/objections on the right value for the parameters for the related PUP (to be posted immediately if and when PIP-22 passes)
Bottom line: passing PUP-14, PUP-19 and PIP-22 together and as is is gives two very distinct and decoupled system behaviors (one focused on validator count and the other focused on servicer count). Once this new state is absorbed, further action can be introduced to further incentivize bidding up POKT to achieve validator status.