The first rule in software development is There Will Always Be Bugs.
All that the best QA on the planet can ever hope to do is catch 99.9996% of them (the six sigma level) - but that's an unrealistic goal for software development in comparison to manufacturing because of variables outside of their control. So most of the time software teams aim for 4th or 5th Sigma, or eliminating 99.3% to 99.97% of the bugs. That means that out of a list of 1000 features that QA tests, 3 bugs are still gonna slip through. Stuff like the localization from Japanese getting missed in one lone instance last patch is an example - out of the hundreds of lines of dialogue in the patch, one got overlooked. It happens.
For the record, the software team I'm embedded in as a business analyst has over 13,000 JIRA tickets over 10 years, of which about 7800 are bug reports. 700 bugs a year! However, only 3200 of those were client reported, and over a thousand of them were marked as duplicates. 200 bugs a year over 4 releases a year, so about 50 reported bugs per patch. For software with about 300 different components and thousands of features and variables. The QA department is about 4 people. We don't have automation functional testing yet because our code is janky AF and we're too broke to be able to outsource it. So we aim for 4th sigma.... 99.7 bug free. And we kind of get there.
CBU3 is probably still aiming for that 5th sigma level as their goal, but it's a goal and not a realistic demand every patch release. There will always be bugs.
And the bigger and more complex the system, the greater the technical debt, and the greater the likelihood of accidental stuff getting overlooked or unexpected interactions, especially when the servers are stressed beyond their original specifications. (Thinking about the timeout bugs during EW.)
I think CBU3 actually did hit it with FF16. The game on launch had some technical issues from people never having dusted out their PS5s in 2 years and others hating the motion blur, but very few straight up bugs.