The way to prevent that is to learn about these optimizations, which change often and in undocumented ways, making your code perform very differently across versions.
If the difference between a game running at 30fps and 60fps is using weird optimizations to compensate for quirks in v8 and spidermonkey, you better believe I'm going to optimize for them. But then script runtime changes later make my performance tank when other (originally slower) pieces of code speed up.
I have a feeling those optimizations apply to all engines because they applied to V8, and maintainers of the other engines attempted to match their performance since so many were coding for performance on V8 only.
So I assume that the 'universal' speed tips apply to JS as well. So far - when I've refactored for speed gains - they have.
This is a very good observation. I think we're getting to the point where designers of languages and programming environments should start paying attention to the programmer cost/benefit trade-offs around optimization. It doesn't matter what language it is, if performance is critical, and your application is well used, you will get to the point where you'll have to optimize.
Optimizing a managed language with garbage collection is hard. JIT and Generational GC tends to make optimization especially hard. Rust takes an approach without GC. Golang has GC, but makes it easy to avoid creating memory pressure.
But then the way it was massively marketed meant those languages died, with Eiffel and Oberon being the only two that are still kind of around, but they are pretty niche.
Thankfully .NET designers learned the lesson and kept value types, some ways of manually allocating, AOT compilation at installation time, reified generics, but "it's Microsoft" meant many did not explore this path.
Java is now trying to fix these bad decisions.
In a way Go is what Java 1.0 should have been.
Not only that, your code can perform very differently across minor changes! All it takes is a single modification to start triggering cascading deoptimizations and lead to severely degraded performance. Even writing 0 instead of 0.0 (or vice versa) can change how the code is optimized and reduce performance.