I am strongly in favor of turning on keep-alive, even by default. Here are some key reasons why.
1) TCP Connect is expensive. There are many stats which are more data-backed out there, but even a quick test on WebPageTest shows an average connect time of 100ms for Cable speed with 28ms latency. Adding 100ms to the time to fetch every resource is a lot, even if some of those are happening in parallel.
2) On Mobile networks, TCP Connect is even more expensive. The same test from above, but slightly modified to use a 200ms latency connection raised the average connect time to 234ms. That’s a lot of time.
3) Keep-Alive is required for the use of HTTP Pipelining. Most mobile browsers use HTTP Pipelining, and it looks like Chrome will enable it by default soon. Clearly the data these browser makers have indicates piping requests is good, and closing the connection each time will take away that value.
4) As @safruti recently reminded me, not knowing your content length (e.g. when gzipping content) does not require closing the connection if you use chunked encoding. So perhaps changing .htaccess should come with some other changes to enable chunked encoding if it’s not already on…
So while there are a few downsides to using keep-alive, I would absolutely recommend using it, as I think its value outweighs its limitations. I don’t know enough about what deployments of HTML5 BP look like to be certain about turning it on by default, but I would bias in favor of doing so.