> GC pauses wouldn't really be a problem if development in the past twenty five years had been focused on hardware assisted incremental garbage collection

Hardware assisted GC isn't free. It comes at a large cost of silicon* and power. And makes a lot of assumptions and puts a lot of restrictions on your GC. And it still doesn't solve the caching problems related to automatic memory management.

* The silicon has to come out of the die budget somewhere. likely decreasing performance on other operations. Or removing other special purpose instructions altogether (SIMD?)

The hardware features required for hardware-assisted GC are actually pretty simple. See https://www.usenix.org/legacy/events/vee05/full_papers/p46-c... for a description. Other features like hardware-assisted write barriers (simple) and transactional memory (much more complex) can be used to increase performance.

So what you're saying(or, implying, as I stubbornly deduce from references to GC, sue me ;)) is that it is unfortunate that we can't use... gasp Java?

Oh dear.

Or the many other GC'd languages game devs might like to use: Python, Ruby, JavaScript, Scala, Clojure ...

Yes, it is unfortunate we can't use those languages and achieve the same performance as manual memory management in C/C++.