A broken inlining heuristic is not going to have the kind of performance consequences for an asm.js app that you get when you get dropped into the interpreter/baseline JIT in a javascript app today.

A function not getting inlined means the addition of function call overhead, and that's it, in most cases. Dropping into an interpreter or baseline jit can literally produce a 100x slowdown, or worse.

Any conforming asm.js implementation that does AOT compilation will produce predictable performance. Yes, individual implementations will differ, but the same is true when you compile applications against MSVC, Clang, and GCC. You don't see anyone arguing that Clang and MSVC should have standardized inlining heuristics, do you?

It's important to remember, also, that when we say things like 'JIT sweet spot' we're not just referring to what code you wrote. It also matters what code you run, in which order, with which arguments. Something as simple as changing the order in which you call some functions (without changing the actual code in those functions) can cause them to deopt in modern runtimes because the heuristics are so sensitive to minor changes in data. Those kind of variances can be caused by something as simple as a HTTP request taking a bit longer to complete and changing the startup behavior of your app.

Does that happen measurably often on hot paths in reality, or is it just a theoretical worry? Because it sounds like you're describing a JIT with broken heuristics.

Yes, it happens measurably often on hot paths in reality. I have test cases that produce it against modern builds of v8 and spidermonkey. Naturally, they are not all real-world examples, but they're based on problems from real apps.