Companies don't upgrade VS willy-nilly. We're using 2010SP1 for instance on a project not planning to ship for several years. Using a newer version would mean buying new licenses to the IDE, possibility buying new licenses to plugins we use, and of course risking some show-stopping bugs that haven't been worked out. We already paid for 2010 and know 2010 will work for our needs though.
I admit it annoys me at times; I really would like the newest C++11/14 support, AMP support, and improved optimizations, but that kind of "upgrade to the new shiny" mentality doesn't mesh well with larger, more serious projects.
Most corporate entities are very, very conservative about updating any piece of software, be it Visual Studio, Office, Windows, Perforce, whatever. While Visual Studio 2005 usage is pretty rare for games today, 2008 is still pretty common. Very very few are using 2012. It's quite possible that uptake of 2012 will never happen en masse and that the next popular version of Visual Studio will be 2013 or 2014.
See for instance how rapid the common enthusiast-oriented Linux distro updates versions compared to the release cadence of Redhat Enterprise or Ubuntu LTS. Home users and hobbiest can more easily justify upgrades and enthusiasts often clamor for them, but businesses typically want as little change as possible.
Another factor today is XBox 360 compatibility. It's silly to buy and install two versions of the IDE/compiler if you need one in particular for XBox compatibility. Which next version of VS becomes popular for games will depend largely on which compiler the XBox One recommends for the release versions of its devkits (2012 is used for the beta devkits used for launch games, but 2013 might be recommended down the road for post-launch titles).
In terms of the runtimes used by the compilers, these must match exactly with the compiler in use. Part of this is because of how C and C++ work. Interfaces are defined by header files, which are really just a fancy way to do cut-n-paste. Consider exhibit A:
void foo(char* name, int length);
And now consider exhibit B:
void foo(int length, char* name);
If these C functions were included in two different versions of the runtimes, they've both be symbol
_foo but the code compiled to use one would clearly not work for the other. While the compatibility problems are generally a bit more involved and subtle, the end result is still the same: code compiled with VS2005 will have header from VS2005 which only describe how the VS2005 runtime works. VS2012 ships with entirely different headers targetting an entirely different runtime.
Microsoft does not support targetting older verions as that would really just be a pain. They'd have to ship and then continue maintaining old headers in addition to the runtimes. There's relatively little reason for it as good DLL usage practices in Windows allow developers to mix libraries using different runtimes. If you have VS2012 you can still link against libraries made with VS2005, so long as you and the library follow a few easy rules.
Platforms like GNU/Linux go through some effort to avoid these issues, but have gone through them, sometimes at a much deeper level. I still recall the libc5 to glibc transition, or the frequent libstdc++ breaks of the time (this is one reasons Linux/UNIX developers have remained relatively cold on the topic of C++ over the years).
Windows does ship with a low-level "generic" C runtime called
MSVCR.DLL, though each version of the compiler include its own replacement e.g.
MSVCRR110.DLL. You can go to effort to use only the generic version but it is missing a great deal of functionality, including most of the C++ support routines that change with each version of Visual Studio (and its ever evolving support of C++). It's generally not worth the effort and lost functionality unless you're really trying to make a zero-dependency application (recovery tools, OS tools, security tools, and so on sometimes fall into this class).
In short, each Visual Studio has its own runtime library, and application compiled with that version must use. Games will typically be written using less than the most cutting edge compiler and hence will require an older runtime.