But isn't Lua very significantly simpler than Python? No MRO lookups, no descriptors, no __getitem__ and the like, no other operator overloading. It looks like turning Lua code into efficient native code should be a lot more doable, in more cases.
Lua does have __getitem__ (it's called __index) and operator overloading. Popular libraries like LPeg use operator overloading extensively. You can use __index to implement whatever method resolution order (MRO) and descriptors that you want (because Lua conflates __getitem__ and __getattr__). Moreover, in Lua, you can even do things like change the metatable of _ENV or _G. So, while Lua is indeed very significantly simpler than Python, it's not clear that the simplicity entitles a compiler to make many more assumptions about the meanings of constructs in your Lua code. The technique that allows JIT to work well for either language is to hoist most of the relevant guards (is this division operand a number rather than an LPeg pattern?) out of the native-code-compiled high-performance loop, bailing out to a slow path if they fail.
PyPy is trying to solve a harder problem than LuaJIT in another way, though: it's intended as a framework for writing a tracing JIT for your own language, not just a JIT for a single language. I've seen very promising prototypes using PyPy's infrastructure for this, but I'm not sure if any other PyPy-implemented language is really ready for general use.
