There's an interesting game programmer problem here, that is somewhat alien to a coder like me who grew up on the web. Where for a web coder, statelessness is the default, and we have to work to recover and recreate state between 'frames', game coders live in the run loop - and so the assumption is that you have a repository of persistent global state to act on each frame.
Having noticed that he has a problem when multiple functions are all interacting with that same shared global state, it's kind of amusing that Carmack's reaction is to reduce the number of functions, rather than remove the global state.
At its core the problem game programmers run into is that game state is very globalized with a lot of dependency overlap. You can push around the data into different containers and declare dogmatic methods of access, but you always wind up with the same problems: The animation state depends on the physics. The rendering depends on the animation state. The physics of a local entity depend on its collision with the rest of the world. The results of physics depend on which things collided first. And so on and so forth.
And so games live within this environment of confusion over which things happen when. At every point there are a few defensive tools - queue up actions in a buffer, poll values instead of copying them, etc. - but the overall management of these concurrent, overlapping systems remains a challenging task lacking in silver bullets.
Having noticed that he has a problem when multiple functions are all interacting with that same shared global state, it's kind of amusing that Carmack's reaction is to reduce the number of functions, rather than remove the global state.