Imagine your execution engine (or whatever you call it) makes the assumption that object references are direct and don't change, for the naturally desirable reason that it wants to be fast. Then along comes somebody who says, "Hey, I want to implement a copying GC!" Oops, then what?
Copying is only one of many garbage collection approaches that involves relocating objects. So does mark-compact, and most of the interesting concurrent and parallel algorithms.
I think you mean "relocating" GC. (By the way, not all relocating GC's today involve an extra level of indirection, so the performance hit to the execution engine is not necessarily what you think it is.)
This code can be agressively optimized (including inlining, array bounds check elimination, nonvirtualization, etc.) by a WAT compiler.. JC being a perfect example. Not to mention the application itself. After all, who only runs an application once? You can WAT compile the application and then all of your code (except for anything loaded & run dynamically at runtime) will run fast.
This argument neglects many of the benefits of JITs. First of all, you can't inline virtual method calls effectively (at which point, you can basically forget about optimizing) unless you know every class that is going to be loaded, which you never do.
Modern JITs can make aggressive assumptions about inlining based on current information and back them out if the information is later invalidated (say, by another class being loaded.) Such speculative optimizations are very effective.
JITs can also make better optimization decisions based on profiling data gathered during interpretation. This is the JVM equivalent of branch prediction -- by the time the code is compiled, the JVM has a lot of information such as "how often is this branch taken" (which can be used to make inlining space-vs-speed tradeoffs) and "how often is this lock contended" (which can be used to make decisions about whether or not to even try thin-locking.) And the list goes on and on.
