If you take spec conformation and safety (but not speed) with higher priority, then those are not problems. There is a limited number of JUMPDEST, but of course more optimizations of the control flow will not be possible. EVM JIT is a thing that sounds attractive in surface, but not so much when all the details are considered.
In revive you are already making contract code 4x the sizes, which is a significant overhead. If you haven’t cared about making the situation 4x worse then another 1x to store the EVM bytecode wouldn’t be that of a big deal.
Just two years ago you would have been arguing with me why Solidity sucks.
Initially we thought EVM sucks so we went with WASM. Then we figured out WASM sucks and went with RISCV. At this moment we have a few “small” things we didn’t like about RISCV so PVM and RISCV are not exactly the same any more.
It’s honestly not a problem that we always chase the next best solutions. This is how we make progress in blockchain. But we have an important constraint, called “safety”, that will always be the first priority over everything else.
If there are no guardrails and if the risks of “almost compatibility” is not explained clearly to the community, someone is going to compile their Solidity contracts, unmodified, to production. It only takes one hack, if we advertise “compatibility” but do not treat compatibility serious enough, before all the Ethereum momentum on Polkadot is killed. That is why the “almost compatibility” approach is a lot more unsafe than the other two approaches “full compatibility” or “some compatibility”.
We had the multisig hack, and it’s our duty to be more careful. If we prioritize speed over safety, we may get none. The speed improvements will probably not be felt by everyone until a long time – the Ethereum mainnet hardly get so congested nowadays.