The common-sense assumption that “an optimizing compiler will make it significantly faster” presupposes ... I think, incorrectly, that CPU execution speed is the ruling constraint; that the code is “CPU-bound.”   In my experience, with all business applications, this is almost never actually true.   If the application is, in fact, “I/O-bound,” then it has CPU-time to burn and an optimizing compiler will do nothing useful for it.

(Bear in mind that an ordinarily CPU-bound activity will be forced into I/O-bound characteristics if it consumes so much memory working-set that it is pushed into significant virtual memory paging.)

The essential code-paths within the Perl compiler/interpreter itself are already well-identified and are optimized.   You can therefore write “almost any old thing” in Perl5 and know that it is being executed in a very efficient way.   But the software is still going to spend a preponderance of its time in either an I/O-wait or even an idle-wait.   The one-time overhead of JIT compiling, and the sustained overhead of the interpreter, is time that the CPU can afford to lose.

I therefore suggest that you need to instrument your existing programs, starting with the ones that are most business-critical and/or that seem to be causing the most business pain.   Why are they waiting, what are they waiting on, and where in the code do the waits occur.   Look most closely at the algorithms, and expect to have to redesign them.   As Kernighan & Plauger said in The Elements of Programming Style:   Don’t “diddle” code to make it faster; find a better algorithm.   Do not assume that the CPU is running “round objects to the wall” because it undoubtedly is not and never could.   Do not make the ruling assumption that an optimizing compiler will do for you diddly-squat, because it probably won’t.

Certainly, there are bona-fide edge cases, throughout the Perl system and its libraries, that are properly handled right now with “XS” code, in C or C++.   These are the hot-spots and they feature heavy bit-twiddling; exactly the sort of thing that these languages are best at.   You might find a hot-spot in your app that could be dealt with in this way, but I rather doubt it.

So basically you didn't understand that the OP is in the process of reviving efforts to create a real Perl compiler, with the explicit goal of making Perl run at speeds within an order of magnitude of optimized C.