Given that much of game development is an iterative creative process, you would hope that iteration is much faster than in other development work. Maybe not for the programmers, though.
I don't see how its any more suited to waterfall than any other industry. Sounds like something game devs tell themselves so they feel better about their bad habits, like how crunch is necessary or how automated testing is too hard.
I assume that in the 'game as a service' kind of long going projects it's different, but I don't have that kind of experience.
If the former, then I would say a lot of large companies end up that way (they tell themselves they’re “doing agile” but in reality are really just doing some form of modified waterfall). If the latter, then I will ask: why is that?
Waterfall might make sense if you know up front exactly what you will build, which as an engine developer may well be the case, but for anybody else, I don’t see how a more agile approach short iterations and tight feedback loops wouldn’t produce better results.
I think that's because our development is supposedly agile and we iterate a lot because we don't know what we're actually building very well (that's not a bad thing). Iteration in game development is much slower and lends itself to a waterfall approach because the developer is the client most of the time. In theory the game should look like a very close approximation of the final version years before its launch.