Is a JIT, not an interpreter. JITs are fundamentally different. I seriously doubt Goby is a JIT yet, to the point I'm not even going to check the source.
LuaJIT is also an outlier. I consider it a solid point in favor of the argument that if you build a language for speed from day 1, you can do pretty well and still build in a lot of nice features. Even so, I understand LuaJIT had to drop some Lua features to get there. However, if you first design your language's features with a lot of focus on convenience, and then try to make them fast without compromise, you end up in the PHP/Python/Perl/Ruby/Javascript space, where no matter how much work you put into it you hit fundamental walls. (Yes, even JS with all modern JIT'ing is not really that fast of a language.) The counterargument to your point is that LuaJIT is pretty much all alone in its position on the performance, despite the fact that other seemingly-similar languages have had orders of magnitude more work poured into their JITs.
I think there's a lot of up-and-coming languages that have learned a lot about designing for performance and while, alas, LuaJIT's future seems dim, I believe a lot of languages like Nim and Crystal and even to some extent Go have learned about how to be nicer languages than C or C++ while not giving up tons of performance. LuaJIT, in my opinion, still has a place of honor in the history of programming languages, far outsized from its actual use.
(Rustaceans may be assured I have not forgotten them, I just think Rust is coming at this from a significantly different angle.)