I honestly don't know why it's not such a big deal for Lua, but given LuaJIT's performance, and knowing that it doesn't do escape analysis I know it must not be a big deal :) In Python it's a big deal because everything is boxed, and your inner loops just get bogged down with allocations, which are expensive compared to arithmetic operations.
LuaJIT being a trace compiler, escape analysis in implicit. As long as a value stays (say) int or float, the code to handle it stays int or float. If for whatever reason it switches type, the code will change to accommodate that -- but as long as the types (and/or values) stay the same, the machine code to handle them will take advantage of that.
I can't speak for Lua, but for C, it's because all memory management is handled explicitly by the programmer - that precludes optimizations where dynamic allocation is replaced with stack allocation. The C compiler isn't free to change such things, and most C programmers already perform that optimization without thinking about it. (I don't mean to imply that state of affairs is a good thing, it's just so ingrained in a C programmer that they don't think of it as an optimization.)
Also, since C allows access to raw-memory by design, it can't guarantee that, say, my memory allocation in function f() isn't touched by my funky pointer-arithmetic in function g(). (Perhaps in theory it could, but in practice this problem is mind-blowingly difficult.)
