That said, OP is basically full of shit. This is absolutely exploitable and people are going to just assume the platform and ABI and spray it against the internet, particularly hoping for mod_php.
OK, can you share a working one so we can test that our servers are fixed?
Also by that measure we're never safe. Which is fine, I think we can agree there are almost always unknown exploits out there but that's not the discussion.
There is more nuance to this as well, it might work, but only in certain circumstances which seems to be where this is going at the moment.
The point is you that the criteria for "am I safe from this vulnerability" is "I have applied the patches and/or config changes recommended by the author of the software" and not "I tried to run the PoC against my system and it didn't work". (nor, as was common in this case, "I have applied some config changes that some random people online feel like should help")
It's memory corruption. That requires some guesswork or understanding of the underlying system (platform + ABI) and heap grooming to actually exploit but that's not a security boundary. Any vulnerable version is just going to get hammered with requests until it either crashes without an exploit or actually gets popped.
"We found a potential vulnerability, but not sure how this would be exploitable, but you better fix it when you have the time"
or a
"Fix it yesterday if you dont want an immediate server burn."
matters alot to small maintainers
PHP does need to invest more in the built-in web server, though. Last time I checked, they still recommend against using it in production.
All other popular runtimes provide a standards-compliant HTTP daemon that any other HTTP daemon can proxy to, it's just the way things work nowadays. Insisting on FastCGI limits integration with more modern web servers and HTTP-speaking middleware.