The problem is internal communication and (especially micro-service where you might have many hops)... latency is often a serious concern. Often the best technology to reduce latency is not HTTP. In fact its best you don't rely too much on the protocol (ie be agnostic). Since you brought up Twitter see Twitter Finagle: Most of Finagle’s code is protocol agnostic, simplifying the implementation of new protocols.
And that leads to the previous segue that perhaps Hoverfly should be written in a protocol agnostic way. I'm not sure if it is (ie how coupled it is at the assumption of HTTP 1.1).
Otherwise I see Hoverfly as just a HTTP proxy tool.. of which I have used similar tools such as TCPTrace and ProxyTrace for ole school SOAP (oh the pain).
The movement behind the HTTP ecosystem is undeniable though, and the common practices for public APIs are moving internally. You might check out an API conference or meetup sometime to see what I mean (not that any of us are obligated to follow this trend; I'm just bringing it to light).
Interestingly, even public APIs with push capability are usually HTTP-based (e.g. Twitter's streaming API, GitHub webhook notifications, etc). I predict most microservices will end up working this way too.