This features a shocking dependence on the C compiler doing tail-call optimization. This, I've never seen before. The code probably blows through the stack if it isn't optimized.
I would have prefered the adjective "clever" over "shocking" :) But you're absolutely correct: it does rely entirely on tail-call optimizations. I hadn't seen this as an actual real world concern. Its stack usage is sufficiently minimal for debugging and development of the project itself. And production code would only ever be optimized. Maybe there are risks I can't foresee, but I'm gonna keep at it 'cause the upside is a blazingly fast interpreter.
The traditional loop around a switch has some advantages. That "break" or "continue" is an unconditional branch, so it is a small piece of code and is always correctly predicted. It's almost free. By doing this, you get to avoid repeating code for every instruction. The common code that happens for every instruction thus appears only once in your CPUs cache, instead of being numerous copies.