The reasons why games are buggy:
Developers an't using the AGILE approach. Not that it's a neccesity, however that how it often turns out to be in the end. A particular gameplay system get coded, finished, documented and in all respects completed until someone comes in and says "Nah, that's not what we wanted really. Go make X change Y and reverse the order, let's get rid of this or that thing, put something else, or more things in it's place.
A system designed specifically to be quick and easy to modify means a lot of up-front work, liberal use of the correct design patterns, more documentation - in essence, more work.
Systems that are expected to be optimized are even worse, as a clever developer will see opportunistic tricks and code in a way that's neither aesthatic, easily comprehensible nor easy to modify. Sometimes a complete rewrite is easier than trying to untangle the highly efficient but impenetrable algorithm.
Regardless, every subsystem, no matter of how properly coded it may be, will eventually deteriorate into a buggy mess of wobbly code held by duct-tape - with each unexpected and unplanned modification for to the codebase. Unless you're working at ID softare, in which case you don't have to worry about having the time to properly refactor the code after some feature had to be hacked in last-minute.
Then we have the lack of communication. A programmer and a designer speak different languages and think in different terms. Either the programmer is also an active participant in game design, or the other way around is the only way for those people to get a much clearer idea of what's being expected and how they should approach the problem. That, or get an analyst middleman to translate from the designer's "vision" to the programmer's "tech specs".
Designers for example rarely think about all possible states and interaction between elements - while a coder is much more likely to ask for how a system should work in abornal or uncommon situations.
Then we have stupid decisions. Choosing the wrong tools for the job. Or the wrong people for the wrong job - Can your water graphics shader specialist write an AI? Sure he can, but he won't do it as good as an AI specialist.
And then there's the issue of code singularity. Back in the old days there wasn't much code, so all of it was kept the same standard.
However with today's monoliths, it's different. The core engine has to be rock-solid, perfectly optimized and exhausting in it's API and feature documentation. It has to be the pinnacle of coding.
Everything around it however, the stuff that describes the rules of the game, things that are likely to be changed often don't require this sort of strict adherence. Since those elements get contantly remade durning the creation of the game, oftentimes with multiple subsystem rewrites, it's comfortable to know you can quicly hack a working solution - both thanks to a rock-solid API and knowing that the solution just has to work properly and can go away with sloppy coding.
What I've noticed is that the smaller and more informal a game dev team is, the more coherent a game is.