Wildcards are not as useful to massive organisations as you would think. The wouldn't
want to have a single public/private pair (that is essentally what a certificate is: the public key to your private one, signed by a 3rd party key that the 2nd party has in its trust list) for
.microsoft.com (nor would Google for .google.com) as a single all-powerful key could be far more hassle should it get into the hands of an incompetent or malicious individual/team. If they had to revoke the certificate for *.microsoft.com then there would be a hell of a lot of administration work to be done to reconfigure each part of their infrastructure and renegotiate relevant internal trust relationships between parts of the that infrastructure using the new keys. While having different keys for everything is a burden when all is going well, the burden is worth taking on the offchance that sometihng somewhere does go badly wrong: the damage caused by any given problem can be limited.
We have wildcard certs for each of our properties, but the resources using those certificates are many orders of magnitude less numbersome than the resources covered by the name of a multinational monster. And even though we use a wildcard for internal resources we get specific keys generated and signed for client specific stuff (if we host any service on .. for instance) just as we have different SSH keys and such for accessing information sources they provide for integration purposes: not having the one all powerful key limits the potential damage (and work involved) should any partticualr key/sub-key become compromised. If out internal key were to be stolen by a malicious entity or accidentally made public by a mistake on our part the no client specific resources would be affected (of course to ensure this separation you need to distribute access to the private keys effectively so that they can't all get compromised in a single event.