I will preface this by saying I haven't looked a huge amount of game source, nor built much in the way of games.
But coming from trying to employ 'enterprise' coding practices in web apps, looking at game source code seriously hurts my head:
"What is this view logic doing in with business logic? this needs refactoring... so does this, refactor, refactorrr"
This worries me as I'm about to start a game project, and I'm not sure whether trying to mvc/tdd the dev process is going to hinder us or help us, as I don't see many game examples that use this or much push for better architectural practices it in the community.
The following is an extract from a great article on prototyping games, though to me it seemed exactly the attitude many game devs seem to use when writing production game code:
  Mistake #4: Building a system, not a game
  
  ...if you
  ever find yourself working on
  something that isn’t directly moving
  your forward, stop right there. As
  programmers, we have a tendency to try
  to generalize our code, and make it
  elegant and be able to handle every
  situation. We find that an itch
  terribly hard not scratch, but we need
  to learn how. It took me many years to
  realize that it’s not about the code,
  it’s about the game you ship in the
  end.
  
  Don’t write an elegant game component
  system, skip the editor completely and
  hardwire the state in code, avoid the
  data-driven, self-parsing, XML
  craziness, and just code the damned
  thing.
  
  ... Just get stuff on the screen as
  quickly as you can.
  
  And don’t ever, ever, use the argument
  “if we take some extra time and do
  this the right way, we can reuse it in
  the game”. EVER.
is it because games are (mostly) visually oriented so it makes sense that the code will be weighted heavily in the view, thus any benefits from moving stuff out to models/controllers, is fairly minimal, so why bother?
I've heard the argument that MVC introduces a performance overhead, but this seems to me to be a premature optimisation, and that there'd more important performance issues to tackle before you worry about MVC overheads (eg render pipeline, AI algorithms, datastructure traversal, etc).
Same thing regarding TDD. It's not often I see games employing test cases, but perhaps this is due to the design issues above (mixed view/business) and the fact that it's difficult to test visual components, or components that rely on probablistic results (eg operate within physics simulations). 
Perhaps I'm just looking at the wrong source code, but why do we not see more of these 'enterprise' practices employed in game design? Are games really so different in their requirements, or is a people/culture issue (ie game devs come from a different background and thus have different coding habits)?