That's fairly likely, and there are several of those projects underway in the forums. Unfortunately the engine is filled with weird macros and their own reimplementation of STL-like types, so any full binding is going to require quite a lot of wrapping.
I think the more effective solution for most developers will be to keep all the engine-adjacent code in C++, but integrate a scripting engine of your choice just with your game logic.
Note that you'll need a language capable of AOT compilation if you want to target consoles which only run signed code (or use an interpreter, which will be rather slow). JIT is not an option on those systems.
His point though is that JITs (like LuaJIT) are often not allowed on consoles for security reasons - they don't allow running of unsigned code. So LuaJIT might not be an option.
As myrmidon said, LuaJIT ships with a very fast interpreter.
What I was trying to say is that, while its not as fast as JIT or AOT, it is still extremely fast (many times faster than the reference Lua implementation apparently).
LuaJIT contains a pretty fast interpreter, thus it makes sense to use it on consoles (with the JIT turned off by compile-time-flags) instead of the Lua reference implementation.
