Game dev in general has a much tighter feedback loop than most software. If you're leaking memory, you're doing that a hundred times a second. If your code is slow you get visual stuttering. If you want performant code you need to think about things like cache coherence, you can't use GC etc.
I agree, but that's really true for questions like "does it run fast"? And those kind of arguably fit into the "legible" camp. Whereas "is it fun?" is a question less able to be formally tested and articulated. It's "illegible".
The tighter feedback loop that helps to answer that question comes from dogfooding.
I agree with you for almost all of this, just a small nitpick:
GC isn't really incompatible with games, for the overwhelming majority of games, it's basically a non-factor in performance if you spend even the slightest amount of time on performance.
It's kind of similar to native code - don't allocate too much, reuse resources, don't leak them uncontrollably.
It's only a problem when you need guarantees (i.e. the game should never drop a frame) but basically no game fulfills that nowadays and it isn't a player expectation.
GC is ok as long as you aren't writing some factorio-like etc. Modern computers are perfectly fine doing shit ton of useless stuff 120 times a second without blinking an eye.
If you're allocating stuff every frame you'll run into problems quickly. Sure, you can use an object pool or arena allocator, but then you're basically circumventing GC.
