core also STUPIDLY allow a block to be treated as filled by having just 5 transactions, with lots of sigops.. so reduce the sigops means more transactions, and less concern over any legacy linear sigop processing delays(yep core instigated the linear sigop delay drama by even allowing a transaction to have thousands of sigops.. all so they can sway people into accepting the LN gateway tx format called segwit)
in a peer-to-peer cash system. a peer does not need transactions of 16k sigops. in most cases they only need 2-5
thus going to that kind of transaction format of low sigops would actually speed up transaction validation where by more than 2000tx under low sigop counts can validate FASTER than 200tx under the current ratio
I haven't really seen any tx's with a large amount of sigops,
here's a tx with lots of outputs yet relatively few sigops. Could you reference some transactions where the # of sigops is very large? I can't really imagine what types of transactions could come remotely close to MAX_SIGOPS (except for attempts to flood the network/overwork transaction verifying nodes).