A better way to do a benchmark to get a tx/s figure is to use invalidateblock to roll back the chain 1000 blocks or so, then restart the process to flush the signature caches and reconsiderblock and collect data from that.
To measure tps on real world hardware we can add together each of the "connect block" times and make an average, but I'm sure the speed of at least some of the steps of the block processing is independent of #txns/block, so to estimate a result for a different block size, only some of the times in each "connect block" would need to be divided by {max #txns in 2-4-8-etc. vMB block / max #txns in 1vMB block}.
For example I'm pretty sure callbacks and writing chainstate is O(1) with respect to the number of transactions, but flush and verify could be O(n) [even though as you said incoming blocks aren't really verified much, whatever makes up the verify time may still at least iterate through all the transactions].