I can't help but feel like many of the detractors haven't even really used pecl_http. It's excellent! After a long period evaluating many of them, I've migrated everything to it. There are plenty of advantages to using it over vanilla PHP or any of the current PHP based implementations.
You can use the same interface (Http\Message) as both a replacement for superglobals and a replacement for the diabolical disaster that is curl_setopt().
It does not place undue load on already overtaxed autoloaders. When I used to use Zend\Http and Symfony\Http, I counted at least 50 classes autoloaded just to represent an incoming HTTP request. Guzzle is not much better than this. Autoloading is the worst performance hotspot in many of the PHP applications I maintain even with opcache involved. It's getting silly.
It can be compiled into your PHP build statically. I do this all the time now. Just clone the pecl_http repo along with the raphf and propro repositories into the 'ext' dir of the PHP source tree, then run ./buildconf in the root of the PHP source tree. There are some configure flags I can't remember off the top of my head too.
The interface for pecl_http 2.0 has been relatively stable. Guzzle is very difficult to trust since they've had so many major breaking rewrites of their API in the last year. If you use the PHP AWS SDK, it continues to depend on Guzzle 4 which shares the same namespace as Guzzle 5, so that can make things interesting too.
With PSR-7 brewing in the background and poised to create yet another slew of poor quality userland PHP-based HTTP libraries, it makes sense to attempt to get an already fully-formed C-based OO interface included in the PHP core. Frankly I'm disturbed that it received so many "no" votes when PHP's default tools for handling HTTP are so clumsy by comparison.
I honestly just can't see any good reason why people would choose a slower, more volatile, less complete PHP-based implementation when pecl_http is already available, actively developed, and of such a high quality.