There were several areas where performance would be critical and that JIT optimization would almost certainly be a significant advantage.
One of my development rules is (a) Don't pre-optimize until you know it's too slow and (b) If you know that specific parts of the code in Lua will be constantly called and they are critical then (c) If it will be difficult to back-engineer if you're wrong then go ahead and pick the optimal performance path.
There are a couple bits of Node9 code in Lua that are constantly executed.
1. A minimal scheduler component that interacts with the C kernel. This executes on every Lua coroutine context switch.
2. The code that remaps the global variable references to make them application-specific. That way global references can't break out of the application.
LuaJIT 2.0.x significantly reduces the overhead for remapping global application variables. I did spend a good deal of time profiling the overhead for global remapping. LuaJIT 1.x was significantly faster than C-Lua. I think LuaJIT 2.x was about 40% faster than that.
Regarding NetBSD: I see now that you're actually talking about the NetBSD kernel scripting. Scripted kernels are a relatively new thing (at least to me) and I see that you're one of the primary contributors to the project that I read about (along with Roberto). I'm not sure how you would leverage the Inferno functionality inside of the BSD kernel itself. I'll read more from the link. Kernel scripting is definitely an interesting area of exploration. Node9 is technically a scripted kernel (or will be), but it's hosted. :)
