XP IS NOT TOO OLD.
XP is pretty old - but more importantly it's outside of it's support-cycle (which ended in 2009). The CRT dropping support for EOLed OSes is not new:
VS in 2012 dropped Windows XP which expired in 2009.
VS in 2010 dropped Windows 2000 which expired the same year.
VS in 2007 dropped Win98/ME and NT4, all three already expired.
VS in 2005 dropped Win95 which had already expired.
2. The CRT can be made to run on XP. And it can still take advantages of the no-real-benefit functions when on Vista+ via GetProcAddress. Damn, you could even provide 2 CRTs if GetProcAddress is an issue (but it's not as the new CRT still uses it).
Using GetProcAddress and so on means that your CRT is now performing more conditionals and more indirected calls than would be the case if you just link directly. This slows the CRT down on all Windows XP, Vista, 7 and 8 machines just so Microsoft can support XP customers. It also makes it much harder to test (because it's fundamentally a more complex program now) and much more difficult to prove that it's correct with static analysis tools.
Microsoft could support two CRTs as you say - a good one for Windows Vista+ and a rubbish one for XP, but congratulations - now Microsoft have to support a whole extra product, complete with security, perf, usability testing and application-compatibility testing. Sure making the change would take half a day to write in code. But you've just committed yourself to six man-months of extra testing. And anyway, loads of websites will come along telling developers who have problems in their application to use the "old CRT that just works", hence losing all of the benefits of the fast new CRT for no gain; essentially this path quickly regresses to a "don't use anything invented since 2001" argument.
So Microsoft could only ever use features invented before 2001. That means you don't get any thin locks (so all heap allocations are slower), and you don't get any of the FLS functions which means the CRT can't ever use light-weight threads, or have to suffer memory leaks which slowly cause long running apps to fail.
3. ... But surely the reasons are the high managers making their weird decisions.
Decisions in a product-team are made by the product-team, not by "high managers". This decision will have been made by the PM of the CRT based on the evidence of the technical people that work for him/her (who actually write the code).
They will have made the decision that the number of lost customers of VS2011 due to dropping support for XP will be less than the cost of maintaining separate (or dual) CRTs - because those customers won't be upgrading sideways (going to Win7 from XP is easier than to Linux or OSX), VS2011 wasn't going to run on XP anyway, and devs that build on 7 for release on XP are few, and can either swap out the compiler, or can copy their solution over to a VS2005-XP build machine and compile it there.