zero-day patching is governed by a whole other set of nasty things. Usually involving management, and bullshit deadlines that were intentionally short. That is not really the programmer's fault.
People also talk about how in the old days they didn't need patches and fixes, things worked out of the box. But that's really good old days thinking. When a game shipped on a couple of floppies or a Nintendo ROM cartridge, they were tiny, and simple enough that one person could know every line of code in the thing. It's a lot different to say you shipped an executable that runs in 64K of memory with all assets drawn by the programmer, and runs on a set piece of hardware, and there were no bugs on launch day, vs shipping a program that's 50GB worth of code and data and runs on any one of possibly billions of system configurations, and there were no bugs on launch day. Sure they could maintain the no-bugs-on-launch day thing, but the problem with that is that with the ever-increasing complexity, nothing would ever get shipped and the companies would just collapse. At some point, you need to ship just to stay in business. For example, consider if Notch didn't release Minecraft until it was "finished".
So yeah, deadlines are shorter than programmers would like, but the programmers aren't necessarily seeing the bigger picture, all the balls that are in the air. So those over-short deadlines aren't necessarily bullshit, even though they were too short for some purposes. If the trade off is between the project having a high risk of total failure, vs the product being perfect at launch, you skimp on being perfect at launch. For example, maybe the managers demanded that this particular product launch by Christmas, so there were bugs in it and a zero-day patch to try and compensate for that. Well, what actually happens if you don't launch by Christmas? It's not just pride, this is about project survival. You end up being Duke Nukem Forever.
Or, consider Daikatana. If Romero had merely launched the game quickly, warts and all rather than a drawn-out project with delays and growing expectations, it would have blown over much more quickly. Those two projects are a result of what happens when the programmers get their way and aren't constrained by money or the pencil pushers. Or it would be one of those games that's never released but people talk about with almost religious reverence, how "it
would have been great". Categorically, whatever is it almost certainly would not have been great, it would have the substance of a Peter Molyneux game pitch. But, because nobody was pushing on the "just get it done!" button, the project failed so people can pretend how amazing it would have been. The exact same forces that cause the game to to be launched with some bugs
also shape the game as a whole, including the parts people liked, and people don't consider that. It's sort of a mythology that developers are in an ivory tower carefully sculpting their master work and then the evil producers come in and say "launch today" but the brave creators say "but it's not finished,
think of the public!" like a scene in a movie. However it doesn't really work like that. What's actually in the game is a drawn-out negotiation between different parties, to design a product that many people will like - so the features that many people like in a game are the same features those "just get it shipped" people were also demanding. They get it wrong, sometimes, but they get it right more often. By definition, or they wouldn't stay in business. Developers left alone without input might perfectly easily make a perfect game that nobody actually wants, or at a time nobody wants it.