And to share some of the less horrible reasons to be on older versions of tools:
You can't just download the latest version of MSVC and target the Xbox 360 or Xbox One with it - their SDK integrations aren't instantly forward compatible. Even if you could, you might fail cert - Microsoft requires you to use specific compiler versions, and specific compiler flags, in an effort to improve security. Keep in mind the 360 wasn't even x86 - just because the x86 compiler had been sufficiently tested for regressions for release, doesn't mean QA was done vetting the PPC compiler.
While Sony has been contributing upstream much of the clang work they've done to support the PS4, I don't know that everything has - and even if it has, I'd rather not spend the time to try and recompile clang myself just to embrace the most bleeding edge of compiler tech. I'd much rather just keep to whatever version Sony supplies. Some of their APIs come as binaries for C++ - I do not want to mix and match compiler versions!
...the above reasons have forced me to have multiple MSVC versions installed at the same time. Which isn't all that annoying until you target pre-release Windows 8 because Microsoft is your publisher and wants ModernUI apps, and you have to wipe - and reinstall - every few months to get on the latest version. And if you install in the wrong order, you get to restart from the beginning.
A number of game studios buy MSVC straight up instead of MSDN subscriptions for various reasons, so MSVC upgrades may cost tens of thousands of dollars (a bit under $1k per head last I checked.) Even if MSVC upgrades are 'free' for you (e.g. you have MSDN subscriptions), upgrading still involves:
1) Getting matching updated binaries for any third party C++ SDKs
2) Testing to ensure the optimizer hasn't found new an exciting ways to break your code via exploitation of (previously benign) undefined behavior.
3) Dealing with an updated IDE frontend, with all it's bugs, unupdated plugins, etc.
4) Reworking build scripts to correctly invoke the new build
5) (Re)installing MSVC across the entire studio, all build machines, etc.
Doing a VS2008 -> VS2010 upgrade of a large codebase required a rewrite of most of our build configuration, in my experience (Microsoft revamped things in terms of MSBuild.) VS2010 -> VS2012 was much less harsh - I could even share build configurations when we had to support VS2010 and VS2012 simultaneously - but getting everyone up and running again after the upgrade was still days of downtime for no gains on our end, except regaining the ability to pass certification.
More in the "bad" column: At home, I have hundreds of projects in my I:\home\projects\dead\ folder. As a result, I still keep VS2008 installed. (I also have VS2013 installed - I may skip VS2015 in favor of VS2016/2017? We'll see.)
