Remember, the quote was from someone attending the AGM and not an average player. He said that 'the codebase needs to be rationalized'. Sounds pretty much like refactoring to me.
Maybe, purely from a symantic standpoint "refactoring" does not involve changing the functionality of code.
If there's a "God function" that's getting huge and many developers are making changes to it, the merging becomes a nightmare right? Your working on your bit, I'm working on my bit, we're changing the same files and tripping over each other in a months time when we're trying to bring it all together - no matter how good the tools are now days - if we're changing the same line, we have to go through the "merge" line by line and say "do we keep your change or my change?"
Seperate out those concerns into different smaller classes/functions/files - bring in some standard design patterns, whatever. The God function becomes a small function that splits out into smaller seperate "concerns" (different files, less code) you can, in theory, work together on stuff that's less likely to become a merging nightmare in a months time. It's also easier to read. The output of the function was X and is still X
That's refactoring. The functionality generally isn't changing as far as the end user is concerned.
If I rewrite the god function to do something different, faster - or drop it completely and add a whole new additional "better" game loop. The output of the function is now Y or gone completely. That's a rewrite.