By statute and out of tradition, the NSA operates in hidden ways. So the exact reasons of why the NSA did something or did not cannot be rigorously known. However, one can make some guesswork.
A first thing to note is that suite B is meant for interoperability: it is a deliberately small list of algorithms and features with the official purpose of being implemented everywhere. For instance, for elliptic curves, they only list two specific curves among the 15 described in FIPS 186-3. So we can assume that NSA included only algorithms which were already implemented in various systems and libraries, or stood a good chance of being implemented in the near future. Nobody uses MQV and nobody really intends using MQV in the foreseeable future...
Now why nobody uses MQV in practice is another question, and the answer boils down to the usual three: patents, uselessness and weaknesses. The "uselessness" part deserves an explanation: MQV is an authenticated key exchange in that it tries to combine the key exchange with a mutual authentication of both involved parties. This is neat, but does not map well to existing communication frameworks, in particular SSL. In SSL, the client and server are distinct roles; the client gains assurance that it knows the correct server public key through the server's certificate, but the authentication of the client, when applied at all, is separated from the key exchange (the client computes a signature with its private key, and the algorithm for that signature needs not be related to the one used for the key exchange).
Another viewpoint on the subject is that if a putative SSL client has a certificate with a MQV public key (assuming that use of MQV with SSL was formalized and implemented), then the client can use that certificate only to authenticate with SSL servers who uses MQV and happen to have a MQV key pair which uses the same elliptic curve. This is rather restrictive, and contrasts with the usual situation where the client has a generic signature certificate which can be used in many other contexts.
Interestingly, use of elliptic curve cryptography in SSL/TLS is defined in RFC 4492, published in 2006, after a long sequence of drafts. The first draft, from 1998, includes MQV-based cipher suites. But the second draft, in 2001, does not. In the first draft, MQV was used just like it was Diffie-Hellman, so without any actual security benefit. In that context, MQV was just a more complex way of doing DH, and, as such, was removed altogether. The alleged benefits of MQV over DH (even assuming that the benefits are real, which is what Krawczyk denies) are made void by the structure of the SSL/TLS key exchange. So why bother ? DH is slightly faster and has a less clouded sky with regards to patents.
Summary: Even without taking into account the weaknesses revealed in 2005 (a few months after publication of NSA suite B), the security advantages of MQV over DH are any good only in specific contexts which are rarely encountered in practice, especially if we notice that suite B is about interoperability, i.e. by definition not about proprietary closed scenario. Correspondingly, nobody does MQV (or when they do, they don't aim at interoperability). In the contexts where the notion of "suite B" applies, MQV tends to have no benefit over a simpler (and faster) Diffie-Hellman. This alone justifies NSA not including MQV in their "suite B".