That's interesting - the standard does say that (17.4.1.1. Library contents)
  All library entities except  macros, operator new and operator delete are defined within the namespace std or namespaces nested within namespace std.
And clearly says that (5.2.8 Type identification)
  The result of a typeid expression is an lvalue of static type const std::type_info (18.5.1) and dynamic type const std::type_info or const name where name is an implementation-defined class derived from std::type_info which preserves the behavior described in 18.5.1.
Ans, of course, the descriptin of header <typeinfo?> indicate the it should be in namespace std (18.5 Type identification):
  Header <typeinfo> synopsis
namespace std {
    class type_info;
    class bad_cast;
    class bad_typeid;
}
So type_info should be in the std namespace (and not outside of it).  I guess that either this is a bug or there's some large set of code (or small set of important code) that needs it outside of the std namespace. I'd have thought they'd use some preprocessor magic to make it so you could force it to be in the std namespace if desired (or the other way around - make it in std by default and allow a macro or something to force it to the global namespace).
However, one additional wrinkle for type_info is that it's the result of the typeid operator (more precisely, something derived from type_info is the result), so there's probably a tight dependency on what the compiler does for the typeid operator that the library  needs to be in line with. So the fact that type_info isn't in namespace std is possibly due to what the compiler does with typeid expressions, and the library writers probably have little direct control over that (and I'd guess that's one reason why there's no preprocssor workaround for the problem). Someone who knows a lot more about how compilers work than I do would have to explain this better (or take it beyond speculation).
But I think you'll have to ask someone at Microsoft (or PJ Plauger/Dinkumware) for a real answer to "why".