I'm sure part of it is just "conventional wisdom" at this point. I agree that you likely could design and implement an effective garbage collection-based memor

I'm sure part of it is just "conventional wisdom" at this point. I agree that you likely could design and implement an effective garbage collection-based memory allocator for game (engine) use cases. I am certain many successful titles have shipped with something you could call garbage collection. In my experience, the expected friction / hatred stems from the idea of a (language-level) GC that you as the developer have little to no control over. i.e. it's not about a direct performance cost/penalty so much as 1: a limiting factor or overhead (e.g. if you don't know which frame the penalty occurs you need to reserve time for it in every frame) and 2: the cost of dealing with yet another layer of main loop system synchronisation issues. The point about value types is relevant, but probably not strictly a GC issue, as you say. Fast value types are absolutely crucial to high performance game (engine) code. Value types to a game developer are stack-allocated. Going to the heap is completely out of the question. Here, "fast" means performance comparable to the basic numeric types.