Presuming the bytecode interpreter would be "slow enough" and "jittery enough" and "indirect enough" to hamper any attempts at exploiting subtle timing+memory layout bugs like that?
IIRC, Konqueror (of KDE) had reasonably fast bytecode JS engine. I wish the browser was still undergoing fast development, used to be my daily driver for many years.
That said, it would make things harder in practice since you’re introducing an extra indirection level and just making everything slower.
As for interpreters in modern browsers, I’d be surprised if there’s no way to entirely disable the JIT somehow... since most JIT implementations I have seen have an interpreter fallback for debugging and easier portability to new CPU architectures.
For spectre simply having attacker directed control flow was sufficient - so logically almost any scripting language could be exploited.
Same goes for most of the TLB attacks.
Others required native code because they needed to use specific instructions (that aren’t going to be emitted intentionally by any compiler - jit or otherwise).