I've always loved the Factorio devs for seeming to make their game not only fun but also a well-designed piece of software. The gamedev industry, particularly by indie devs, is notorious for doing whatever it takes to make it work, code health be damned.
It's because in most cases investing in "code health" beyond what they already do is a mistake in the game industry. Games are mostly disposable products. Only when you're going to be maintaining it a long time does the investment pay off.
One of the key considerations nowadays, though, is that games are far less disposable than they were in, say, the 90's/00's; there's an expectation that players will be getting bugfixes and features and even expansions/DLC for a long while after the original release date. That confounds even further with the recent trend of "Early Access" and similar schemes for player-driven alpha/beta testing.
I'm not sure that actually holds, or at least we would need to split up the games industry to see how it applies. If we're talking about games specifically designed for long-term play and ongoing updates (Dota 2, CS:Go, Fortnite, etc.) then yes I agree. If we're talking about your standard AAA releases likes CoD: whatever or most indie games, it's generally a "get it out the damn door" situation because the sales graph is extremely downward sloping over time.
There's also a bias in here because if you're using "old" games like AoE II as examples, they were released back in the day before patches were really an accepted thing, so there was a lot more effort that went into solidifying a game before it went gold than there is today.
There's lots of indie games that get tons of updates, too. Minecraft is the big one in this space that kinda defined the model, Factorio is one of them too. Dwarf Fortress has had regular updates since 2006.
Get a playable version of the core game into Early Access for a low price, start releasing updates. Your player base provides feedback on the game as it evolves, free beta testing, and growing word-of-mouth promotion. Maybe even ideas for entire systems, especially if you have mod support. Eventually you expand it to have all the stuff that was in your original vision, and you bump the price up for the 1.0 release. Port it to consoles, decide if you want to keep on adding new content to make it the game you barely dared to dream it could be, or move on to the next project.
There's still people who keep a game quiet until they can release 1.0, but there's a lot of small games out there that get their stuff out in public as soon as possible.
Similarly, a lot of games built with Valve's Source engine get continual updates even today - a decade or more after release - specifically because Source gets updates and therefore so do the games built on it. It's interesting to see updates come in for Half Life 2: Deathmatch even though absolutely nothing player-facing has changed (to my knowledge) since the 00's.
The game engine is reused between most games in a series, e.g. CoD, so there is still an incentive to invest there. They skimp on story/art/content though.
I think a big part of that is that historically most games are updated relatively little after they are released, so maintainability of the code base is secondary to not letting the release date slip. But Factorio is a game that has been getting updates for a while now post-release, so the devs have to be happy revisiting the code, which increases the incentives for keeping the code maintainable and the code health high. It seems like more games are moving towards this model (lots of updates post-release), so I'd expect to see the game industry start to adopt some of the practices used by the software industry in general to keep code maintainable.
I think rather it's a revenue issue, until relatively recently there was no way to profit from updated games, so you're better off moving on to the sequel, or next year's edition of the game. Also a lot of the video game development culture likely stems from console releases, which again until "recently" could not be updated (only new versions of disks/carts for future customers) so it was not feasible to plan for future maintenance, beyond what was necessary for derived codebases.
it's a hit driven industry, so maybe the dynamics are pretty startup-ish: you don't know if the product is going to take off, so cut corners to reduce costs in the short run at the expense of future maintainability, since you don't know if the product will be profitable and have a future until after it ships.
if the product is wildly successful and has a future, but is a bit of maintenance nightmare: congratulations, that's the problem you want to have
