Because it doesn't need it. Technically no website needs it. Only people who don't know how to type "https" need it.
It's obvious why it can be a grand target for Man in the Middle, defacement and worst of all integrity attacks. Apart from preventing many of the latter, implementing HSTS could have really mitigated the problem. Anyone who had already visited the site wouldn't see the defaced page. Furthermore, they could get added to an STS preloaded list[1], making the attack invisible to anyone using a modern browser.
If you are interested, the Wikipedia page[2] does a fair job at explaining more about why HSTS is needed.
[1]: https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr...
[2]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security...
But this is all crap, really. OpenSSL is a library distributed across tens of thousands of independent providers all over the internet. Nobody needs to get it from the main site, and even if they do, there's a multitude of ways to tell if it's the real deal or not. If you know what OpenSSL is, you can type in "https" and be totally secure without HSTS. Even if you needed HSTS (which you don't), who's going to the OpenSSL.org website time after time that HSTS would even be useful?
People make way too big a deal over half-baked countermeasures that don't apply to every case. You find me the person who's downloading vanilla OpenSSL libraries from the main site over multiple visits and is at risk of a client-side MITM and not verifying their sources, and i'll show you someone who's going to get owned even without a MITM.
Furthermore, it's just embarrassing to see such attacks on these high-profile sites. If they can't defend their site (even for users who don't type "https://"), who is to say their library is secure? These kinds of attacks threaten the confidence we have on our fundamental cryptographic building blocks and should be avoided.
1. These attacks don't bear at all on cryptographic building blocks, because any script kiddie can brute force a login or fuzz an input, etc. Has nothing to do with crypto at all. Has nothing to do with their code at all. Completely different systems with completely different attacks with incredibly different requirements... it's worlds apart. There is nothing about defacing a website or even MITM that could ever be compared to breaking a crypto library.
2. HSTS is quite a bit different from the PKI of TLS. That said, what you are basically saying is "HSTS is the same thing as HTTPS when you add the URL to the browser's STS whitelist". (Which could be avoided altogether if you just type "https")
So what your argument really boils down to is: a crypto library is worthless because we really need to use HSTS because OpenSSL.org users are too stupid to type "https".
Not only is this inaccurate and nonsensical, it's just a crappy security model. Now I have to manage HSTS exactly the same way TLS certs are managed and basically reproduce one protocol into a pseudo-protocol and juggle both, keeping things like RFC 6797 in mind. Suddenly the complexity's gone up enormously over time, only to prevent MITM on the client, and we don't even consider whether or not the content was compromised before the connection of the client to the server.
Even if the server is hacked, you still have absolutely no guarantee if the content was modified, because you're not verifying the content once you download it. But sure. Let's freak out about the possibility of a one-sided MITM to the client over HTTP (which every idiot knows is not secure by design), because that's clearly the most important or likely attack to be worried about right now.
Also, you're forgetting about browsers that ship with lists of HSTS-enabled sites.