I haven't looked at LuaJIT yet but considering how small it is I'm sure it meets or exceeds the quality of the code behind Lua.
Standard Lua (the one from PUC-Rio) doesn't really, it uses boxed numeric values, as I imagine ruby (and almost every other dynamic language) does as well. "Boxed" meaning that each number is stored on the heap with some kind of tag, and when you pass such a value to a function you're really passing a pointer to it and that indirection costs cycles and puts pressure on the cache. LuaJIT's most significant (IMO) feature is that it stores numeric values directly, like C does, so when you call a function the actual bits representing it go right on the stack, not the address of where the bits can be found, and it uses some cool tricks of floating point representation to prevent the garbage collector from trying to follow these stack values as if they were pointers. This (combined with the trace optimization) is why when you write a numeric for-loop in LuaJIT it runs (nearly?) as fast a C.
LuaJIT 2's NaN tagging alone does not speed up the stock interpreter: http://article.gmane.org/gmane.comp.lang.lua.general/44823.