It comes down to the fact that in hard real-time you care about doing things in bounded amounts of time, and in soft real-time you typically want to do things "as fast as possible" and fixed-cost incremental GCs tend to be comparably high fraction of CPU usage versus a good generational stop-the-world collector.
Many hard real-time systems already operate with an excess of CPU power in order to simplify analysis of scheduling. Furthermore you are already bounding things like allocations, and a simple incremental GC that runs on a timer tick can guarantee to run in fixed time if you have bounded allocations per timer-tick.
All of this is somewhat moot though as many hard real-time systems completely eschew dynamic allocations.
Many hard real-time systems already operate with an excess of CPU power in order to simplify analysis of scheduling. Furthermore you are already bounding things like allocations, and a simple incremental GC that runs on a timer tick can guarantee to run in fixed time if you have bounded allocations per timer-tick.
All of this is somewhat moot though as many hard real-time systems completely eschew dynamic allocations.