I don't think that there are many other candidates.
Our runtime functions aren't hardened, aka. many of them just crash on incompatible inputs.
Given that we have full control over how and where we call runtime functions, we probably won't have much interest in hardening them further.

Yes, this is WAI.

A few years ago, we tried the approach of explicitly fuzzing all runtime functions. That turned out to cause lots of churn for little to no benefit. So we have learned the lesson that it makes more sense not to fuzz runtime functions. The purpose of the whitelist is to allow fuzzers to use a few runtime functions that make generated fuzz tests more interesting (%OptimizeFunctionOnNextCall is the canonical example -- it's not interesting in itself, but it helps generated tests hit more interesting codepaths elsewhere).

The only additional runtime function that comes to mind at the moment that we could add would be %OptimizeOsr(n). This one triggers OSR (on-stack replacement) of an activation on the stack. Note that we would need to make it fail gracefully on "n" not being a number first, before we add it to the whitelist. Not sure if it's worth it though, as this can always be achieved by making the loop that triggers the OSR run longer.