There is also the more-philosophical matter of ... “why do we use XS?’   I think that a careful examination of that question will lead to the IMHO that Perl5’s way probably does make sense.

Basically, we use XS because of the “80/20 Rule.”   80% of the execution time is spent in 20% of the code.   Therefore, 80% of the code is not particularly time-critical, therefore we have lots of more-or-less equally good options for how to build those things.   Writing those things in a high-level language and running it under an interpreter is “more efficient for us,” so we do most things that way.   Which leaves:   XS.

The interpreter, in its lugubrious way, will hand off control to the jackrabbit, which eventually will hand the car-keys (and a result) back to the interpreter.   Any API that does for the jackrabbit what the jackrabbit needs, without slowing the jackrabbit down too much, is all that is required.   We don’t need fancy-pants.   We just need amazingly-cool C/C++ code in the hands of a really great compiler.

And the internal design of the interpreter doesn’t matter that much, either.   Bytecodes or parse-tree, take your pick.   That portion of the overall program will probably spend most of its clock-time in some wait state or another, spending milliseconds(!) asleep, so it actually doesn’t matter too much (within reason) how fast it runs when it’s awake.   “Refactoring” that part probably won’t pay-back the effort spent to do it.