I don't think it's logical. Stock PHP can easily handle a website with 250k monthly visits. Or, rather, your speedups will most likely come from talking to the database less, doing less IO, that sort of thing. CPU probably isn't your bottleneck now.
The ironic thing about Facebook releasing this is they're (and a handful of other sites) are the only ones that would really benefit from this. I do love that they release it as open source.
At my last company, we handled about 20 million API requests a day through a PHP API. Granted, the request and response were smaller than a standard webpage, but that was using stock PHP (hell it wasn't even custom compiled, it came straight from the Debian packages).
So, you need to hit a pretty huge amount of traffic before something like this makes sense. Of course, it's always neat technology to play with.
Not everybody using PHP is serving web pages. Zynga use PHP to do server side game simulation, I expect there are a myriad of smaller companies doing CPU intensive tasks in PHP that will welcome these developments.
Even when you hit 800m, you'll be fine. Your performance gains will be outside of PHP via good cache usage, (opcode cacheing as well, but that should go without saying), avoiding hitting the disk or the DB, etc.
