I wrote games and engines in C++ for 15 years, and Unity for about 5. I strongly prefer manual mem management, hands down. Optimizing for Unity's GC, in pathological situations, is the nightmare.
If the game is relatively simple, and the heap relatively small, it's not a big problem. But if you're trying to make a large, complex simulation that's actually pushing boundaries, the GC becomes a constant adversary. People always talk about allocations, but not allocating during a frame is just the minimum price of admission. The real trouble is the static characteristics of the heap, like size and graph complexity. With manual alloc, at least the problem is straightforward: don't leak, and don't dangle. With a black-box GC, where you can't even hint to it about the lifetimes of objects, you have to be much, much more aware of memory management, then go through a lot of different non-idiomatic contortions regarding every single thing you put on the heap.
If the game is relatively simple, and the heap relatively small, it's not a big problem. But if you're trying to make a large, complex simulation that's actually pushing boundaries, the GC becomes a constant adversary. People always talk about allocations, but not allocating during a frame is just the minimum price of admission. The real trouble is the static characteristics of the heap, like size and graph complexity. With manual alloc, at least the problem is straightforward: don't leak, and don't dangle. With a black-box GC, where you can't even hint to it about the lifetimes of objects, you have to be much, much more aware of memory management, then go through a lot of different non-idiomatic contortions regarding every single thing you put on the heap.