And Lua has proven itself in limited/constrained resource environments for over 20 years. In practice, it is really good in this space.
And a further interesting point about Lua somebody pointed out to me...now that most modern architectures are cache oriented and memory buses are often the bottleneck, it is amazing that Lua is small enough to fit in the L2 cache. Think about this...it is almost like having Lua in hardware on the chip.
Note: Canonical PUC-Rio Lua does not have JIT. You aren't burning all the cycles you think you are if you are applying typical arguments about the JVM or JavaScript JITs.
Edit: typo
Anyway, there is no point at all (zero, full stop) in using a dynamic language in embedded, where all your code is fixed and rarely updated, with no runtime metaprogramming (eval and such).
And, sorry, but there are far better uses for the L2 cache than keeping any fat interpreter there. I would have accepted a cache locality argument for a direct threaded code (and that's the reason why Forth rocks more than C in embedded), but not the Lua kind of interpreter.
Lua on the other hand, won that test plenty of times.