You're right, I only have a vague understanding of "game development". I was too busy delivering working enterprise software for the past years to look into that. One dev in my team was once developing games for a small publisher, though. He says it was hell.
How about we skip the ad hominem and get to the facts:
A bug breaking something that has already worked in a previously released build should not happen. No matter if it's a game or any other software. But it happens every time with a new KSP version. It has become custom to wait for the first hotfix after a release until you can actually play. This should not be necessary.
There are multiple ways to mitigate the risk of introducing new bugs or breaking existing features. Even more to prevent them from being released. Some are organizational, some are technological. Automated testing, pair programming, mob programming, pair review, regression testing, exploratory testing are just a few of them.
What works best? The Agile tenet holds true here: Inspect and adapt. Find out what fits for your circumstances and implement it. But: the inspecting has to begin at some point.
538 issues in KSP's bugtracker have not even been looked at. Ever.
Maybe half of them aren't even bugs or are outdated. Who knows? Well, nobody, because nobody seems to take the time to analyse them. For me this is an indication that not enough resources are spent on quality. I am not even talking about code quality, I am talking about taking the reported income and acting on it.
Yes, I build gigantic vehicles in KSP, it's kinda my thing. But I was able to build 1600 part battlecruisers in KSP 1.0.x without ever experiencing the amount of memory grab KSP performs nowadays. The problem lies with fairings and the new structural panels. As soon as a decent amount of them are in play, the game goes into nightmare mode. Especially if you work with subassemblies and delete and load parts of your vehicle. One quick fix could be to disable the fairing preview animation or the many attachment nodes on the new panels with the press of a button.
To re-iterate, this type of problem was not present in previous versions, even with significantly more mods. I know of other KSP players and YouTube creators that stick to version 1.3.1 due to this and many other issues.
And as I mentioned in the video, bugs are only part of the issue. The problem with technical debt is that over time a development team starts to work itself into a corner if they do not get rid of it.
You chose one library over the other because it's faster to implement but you know that the other one would have been better in the long run. You hack your code and leave //TODO comments that will never be looked at again. You hardcode stuff instead of doing it the right way.
All of these things enable you to get your product out on an arbitrarily set release date. But it's like taking up a loan with high interest rates. In the long run it will cost you more. And if you don't pay it off, the debt will pile up.
Usually it's mismanagement - not believing developers when they say they need more time to get rid of tech debt - that leads to the mentioned flatline in my video.
Don't just take my word for it, maybe the father of the Wiki, Ward Cunningham, might convince you:
I would very much like to know how KSP development is organized nowadays. Are the team or teams colocated? How is testing set up? Is testing (and in what form) part of the definition of done (if such a thing exists)? How is the release validated before shipping? How is bug reporting handled? Is this also the job of the developers (it shouldn't be) or are there dedicated support/quality engineers looking tat the new income and analyzing it?
There are so many ways software development can be improved. But as mentioned above: somebody has to start the inspecting before the adapting can begin.