Because Facebook also has a reputation of not playing nice with people, the rules, intellectual property, and so on. This is hardly a company anyone should support or trust and if you can't figure that out, I can't help you.
As far as their work on HHVM, it was necessary due to failure by bad technology choices from the start. There's very little interesting about this work unless you somehow love PHP, want to make debugging your production applications more difficult, and refuse to address your real problems. I am 100% sure no one outside of the PHP community cares about anything Facebook has done in C++.
Simply having a large company with lots of developers who might have even had good reputations elsewhere or even be smart doesn't mean much. Having worked in many places with lots of smart developers, I can tell you stories about too many geniuses in the room. Calling Facebook developers engineers is also about as apt as calling janitors sanitation engineers. We're programmers, or developers, or perhaps software architects at best depending on the position. I happen to have an EE and CS degree but given I do programming for a living, I'd hardly call myself an engineer. But we're way off topic :)
Actually, game companies as well as various indie developers have widely distributed this knowledge. Some examples of places to look/things to search for implementations or similar/better:
-GDC Slide Decks
-Game Programming Data Structure/Performance Books
-Game Industry Publications - ex: Game Programming Gems
-EA STL
-Game Dev Sites
-Any available source to various engines/games in the last many years should have more than a few inside
Moreover, this is also a common thing in a lot of embedded and high-performance development in general.
Just because someone didn't make a github project and post it on HN doesn't mean it doesn't exist. This seems to be a trend with web developers - reinventing what exists without properly checking what is there, and doing so usually poorly. I say this as someone who has done game development and web development at various points of my career (currently web by day, game by night) so I am not trying to be condescending, just pointing out an unfortunate trend.
Downvote if you want, but I see the first game dev who replied already confirmed what I said.
I really like automators like IFFT as they save the time from having to yet again keep up with breaking API changes from crappy company xyz (ex: Facebook). The problem with all of them seems they don't actually work reliably.
I tried IFFT a number of times. I'd love for it to work, but I only use it as a "it's ok if this breaks, missing data, etc." tool. Admittedly this is not 100% their fault as you are at the mercy of the shoddiness of other APIs, but bugs upon bugs and the less than reliable nature of IFFT actually executing things in a timely, durable manner makes it 100x less useful and impossible to build on top of for real apps.
I also feel that from a business point of view, relying on other people's services is consistently a trap. Whether it's social networks like Twitter, COTS like SharePoint, or something like Evernote, it's always a trap. These businesses can break your code at any time they choose, shut off your service, or simply go under. It takes a lot of work circumventing their bugs and terrible APIs as well. Hats off for trying, but I don't feel like a company like this is usually a good long-term investment.
Add to these problems the fact that most internet "typical" users would never use IFFT or "get it" the way it's presented today. Moreover, most programmers want more control, something more powerful, or can just do everything here better themselves exactly to their use cases. Not seeing how this company is worth much even if it is "useful." Profitable != useful many times.
Greetings Facebook, several decades ago welcomes you. Game programmers figured out the same and arguably better ways of doing this since each version of std::vector has been released. This is but a small reason most of us had in-house stl libraries for decades now.
Most of the time if performance and allocation is so critical, you're better off not using a vector anyway. A fixed sized array is much more cache friendly, makes pooling quite easy, and eliminates other performance costs that suffer from std::vector's implementation.
More to the point, who would use a c++ library from Facebook? Hopefully don't need to explain the reasons here.