You seem to have a very low opinion of other people. If these miraculous collectors are so generally applicable, why are very smart people putting effort into things like Perseus?
Of course, this assumes you're in a preemptive environment with access to other threads, etc.
You insist that offloading other allocations to a GC running on other threads somehow grants the current thread control over its own scheduling.
This is false.
One can say that you can't really control latency unless running under a RTOS and thus we shall never attempt that. This is also false.
There is no conceivable reason one should not assert absolute control upon what his own code does. GC injects uncertainity into that. This is intolerable.
No, I think GC is the way to control latency of memory handling. Plenty of work on real-time GC shows that you can construct a GC such that if the mutator allocates less than X MB/second you can achieve reclaim latencies under Y ms. The nice thing about these guarantees is that they're global: it doesn't matter how you allocate. All that matters is how much you allocate. It's a metric you can measure and optimize, IMHO, more easily than you can try to bound heap-manager contention and free-SCC size.
Granted, you can come back and point out that it's hard for me to prove I don't have allocation-rate spikes just like it's hard for you to prove you don't have lumpy free()s and malloc pool contention. But IME, it's a lot easier to bound latency rates, because we have good allocation profilers and in many cases you can prove allocation caps. IMHO, it's much harder to reason about long-range interactions of threads touching heaps.
The one primitive I wish we had but (outside BEAM) don't is object coloring. In a GC system, I should be able to allocate objects from different heaps and GC them independently .This way, a can write a subroutine that I can prove locally obeys the allocation-rate rule for my latency target and doesn't do any global allocations without giving up the use of the global heap for other purposes. They'd be a bit like the explicit arenas your tribe uses. (Your child heap would count as one "object" for purposes of parent-heap retention.) You could probably adapt existing multi-pool systems like MPS and ART's GC pretty easily too.
But even absent QoL features like these, modern GC is plenty suitable for programs that need to be responsive.
I feel I have to insist that to control latency one has to first eliminate any intrinsic source of it (a GC) and only then deal with what's left (using arena/pool allocators and such) in the face of even soft realtime requirement (which imo should be the default unless utterly impossible).
This is comparable to what you say about coloring, like, if say java had _both_ GC and zig-like allocator api, so one could have fine control over what is happening. Unfortunately it does not, and the idea of not putting all eggs in one basket is somehow unthinkable.