As the author of 1 of the posts you reference about the number of bugs found, you've misunderstood the words. Please re-read them.
On the STS, a "bug" is when the software did not meet the requirements. It didn't necessarily mean something bad would happen, just that the code didn't match the requirements. The developers didn't classify the bugs. For overly complex bugs, a developer might be asked for analysis. Nothing was called "a feature" if it wasn't in the requirements. That would be a bug too.
Additionally, the developers weren't allowed to fix bugs without formal authorization. We weren't allowed to change any line in the source that wasn't directly related to the change authorization we were working under. We weren't allowed to change indentation to make the code more readable, unless our changes nearby were significant enough. These restrictions were to prevent accidental changes, which would lead to accidental bug introduction. Every line changed was tagged to a specific individual and CR/DR authorization.
Especially with guidance calculations, sometimes the requirements couldn't be implemented due to limitations of the computers. In real-time coding, a late answer is just as bad as a wrong answer. At least once, the requirements needed to be changed to match the code.
Nobody knows the real number of bugs in any software at any time, but Jim Orr literally wrote the book on Space Shuttle software issues and errors. He was provided all the data on requirement reviews, design reviews, testing plan reviews, code review and test results when I worked there for the GN&C FSW
There were definitely hundreds of bugs in the FSW, very few were considered SEV-1. None would cause a computer lock up or other typical error people put up with in their lives today.
The GN&C code didn't have issues like typical desktop or server code does. There wasn't any dynamic memory allocation. Use of pointers required a written, approved, variance from the SW standards board. All the code was formally peer reviewed by at least 6 people. More complicated code would be reviewed by 20+ people - in the same room.
Over the decades, the process used to create the software was always improving. The process was setup in such a way that it didn't rely on super programmers to create relatively bug free software. It really was all about the process.
Over my decades writing software at many different companies, I've seen that everywhere else depends/hopes on the super programmer idea to produce better results. The problem with this is that super programmer isn't easily reproducible. I've seen it work 1 place and only because each programmer considered any bug a personal failure. Everywhere else is stuck with good, average, and bad programmers. Especially in larger organizations, the scale seems to shift towards bad more than other places. There are always exceptions and obviously, even if I've worked directly with 3000 programmers professionally, that isn't all programmers everywhere.
Hope this clarifies and is helpful.