Well I wasn't arguing with that claim, but rather pjmpl's references to what Tim and John said, that I believe should be taken with a grain of salt.
With regards to GC, do check out Unity3D new ECS/Job system/burst compiler. Essentially sidestepping the garbage collector, C# safety checks, while trying to work with the how the new generation of CPUs are designed to perform.
They aren't sidestepping the garbage collector nor the C# safety checks for the whole engine, because HPC# is only used in a very focused area, everything else is plain old C# as always.
I can also state that in the old days C wasn't worthwhile to be useful as a programming language to write game engines, because proper game engines were written mostly in Assembly with C, Pascal or Basic as their scripting layer if at all.
I'm a Unity developer. I'm well aware of what the ECS/Jobs/Burst architecture brings. I still disagree with your assertion. Note the fact that this data oriented pivot occurs NOW with Unity. It's managed to do pretty well up to this point despite NOT having that feature. Using GC didn't stop it becoming wildly successful.
No where did I say that the GC hindered Unity's boom in anyway. In fact I do agree that the GC, together with C#, allowed Unity to be wildly successful. But it did so by allow too many people to write sloppy code that has performance problems. And that code would leak memory all over the place without the GC. It is sort of eroding the art of programming.
With regards to GC, do check out Unity3D new ECS/Job system/burst compiler. Essentially sidestepping the garbage collector, C# safety checks, while trying to work with the how the new generation of CPUs are designed to perform.