I'm 99.99% sure that these bugs are all from wrong values in a database, which means version control isn't really the problem. The problem is configuration management. Basically when they last fixed these problems someone whipped up a script to correct the values in production and then that script was never integrated into the standard build process. So then the next time someone makes a change and does what they're supposed to do they overwrite the previous fix with the "correct" values, as far as the deployment process is concerned.

The correct way to approach deployments in this kind of system is to have a set of scripts that can rebuild the static portion of your database from nothing, and a set of change scripts that do updates from the previous state (ie: update dropsuits set highslots = 1 where name = dragonfly). That change script gets put into a folder called 1.8, and then when you deploy you run a batch that executes every sql file in that folder. All this stuff gets stored in version control, so that at any point in time you can revert to any version configuration you've ever had.

Then as long as you follow the process of creating that file the guy doing the deployment can't screw it up. If something does go horribly wrong then they can go back and rebuild the whole thing from scratch with the correct values.

It isn't really something QA can catch if the configuration management is wonky. The values could be correct on their internal tests but wrong in production, and there isn't time to test every possible use case in the game during a deployment window.