I suspect it's more likely that he was making enough changes to core game mechanics that it was easier to just redo everything than it was to go back and update every individual event. Depending on the complexity of whatever you're trying to do you could quickly end up in a situation where you've broken something and you're wasting huge amounts of time trying to figure out what you broke.
The best example I can think of is from when I first started modding and I would bang out the coding for an entire update and then try to bug fix the entire update with zero testing during the coding phase. There were times where I was running around in circles to the point where I had to just scrap the whole update and start over. An experienced dev would probably know better but I'm a self taught novice.
Turns out it's a lot easier to code small chunks and test each small chunk as you go. Tough to do that if you're updating a large section of code that's already done though. Where do you delineate the parts you've updated and need to test vs the parts that haven't been updated yet? I have no idea if that's his line of thinking on the matter, but I definitely found that if I test as I go, I end up spending dramatically less time overall to complete and bug fix the same amount of code.
The more branches and inter dependencies you have, the easier it is to find yourself chasing your tail trying to figure out what you've screwed up. Sometimes it's not as simple as a crash where you can usually point to an error that gives you an exact section of code to start looking at. The harder issues to find are things that aren't throwing errors but are not working as expected and you don't know why.
