by lowering the txsigops (not fake the maths) you can both allow more tx's in and reduce the CPU demand of native tx's
Both points are wrong. This:
1) Does not allow for more TXs. All it does is disable some use-cases which require more sigops.
2) It does not reduce CPU demand at all. Those 1k sigops still have quadratic validation time.
1. it does. because having say 1k txsigops and 80k blocksigops vs 4k(mathematically twisted to be treated as 16k) means you cannot use up all the blocksigops with 5-7tx's but instead need 80+ tx's if your malicious
also
by having 1k sigops for instance it helps keep people to making lean tx's more. ask yourself why should anyone have the ability to make 1tx that uses up 14%-20% of a blocks limit.
2) quadratics of 4k of a few seconds vs 1k thats only a few milliseconds per tx..
EG 80x 1k tx sigops with 80kblocksigop = under 2 seconds CPU time per block..
EG 5x 4k txsigops with 20k blocksigop= under 50 seconds CPU time per block..
EG 5x 4k txsigops(math manip to 16k) with 80kblocksigop = under 50 seconds CPU time per block..
EG 5x 16k txsigops = under 50 minutes CPU time per block..
so 80x 1k txsigops with 80kblocksigop = under 2 seconds CPU time.. is better than
SFSW: 5x 4k txsigops(math manip to 16k) with 80kblocksigop= under 50 seconds CPU time..
and better than removing the cludgy math to get a HFSW
HFSW: 5x 16k txsigops = under 50 minutes CPU time..
do the maths
1 tx of 80k sigops vs 80tx of 1ksigops... both total 80k total sigops. but bcause its broken up into different tx's the CPU time changes where 80tx of 1ksigops is much much better for all reasons