At a prior job (writing database kernels in C++), code commits were automatically rejected if any core operation had an observed tail latency of 1 millisecond under stress tests. Also a way to become unfortunately familiar with storage firmware behavior. A GC with a worst-case latency in low milliseconds is a big improvement over the bad old days I remember, but that is still too high for data infrastructure performance-engineering.

The effectiveness of some key optimizations were sensitive to how tight we could make tail latencies for important operations, so a GC always had an unacceptable cost to the extent it occasionally introduced a stall at an inopportune moment. If GC stalls were more like 10 microseconds, consistently, that would be much more viable. I have no idea if that is realistically achievable.