Bodging up old crap is part of the industry. We now use HTTP mostly for asynchronous RPC, TCP streams for reliable datagram protocols that suffer from head-of-line blocking as a result, and a scripting language thrown together for basic form validation as the focus of intense JIT development and back-end work. Oh, and let's not forget NAT and bodging HTTP/2 (which fixes HOL blocking) to, likely, only exist over TLS on TCP port 443.

Facebook were forced down the road of supporting PHP because, just like everyone else everywhere else, they found it is several orders of magnitude more expensive to bring good features and lessons learned to a completely new language, stack or framework.

Its kind of awful that new projects will see this as a new lease of life for PHP, rather than life support, but that's just inevitable. I guess it's both.

In many cases, PHP very definitely being one of them, what we ended up with wasn't invented at all: it grew organically for a while from something much smaller (or sometimes even something quite different). People use it because it is good enough and additions keep being made with little call for standards until you have a huge pile of stuff that many people are relying on. At this point a proper redesign from the ground up is impractical, you have to make step changes, so fixing the mess takes a long time.

PHP was not initially intended to become what it has: it wasn't invented to be what it has turned out to be. But don't complain too much: dealing with that sort of legacy is what keeps some of us in active employment! (not them I'm implying anyone causes these issues on purpose, you'd have to be both a special sort of evil and a special sort of intelligent to create PHP4 (I've not used it since then, things may have improved massively recent years (they were certainly promising to) and I'd be non the wiser) with all its problems on purpose)