why not multiple, short-lived HTTP/2 connections?

I've raised this issue before on the list but it's been a while and reading Mark's ops guide doc (https://github.com/http2/http2-spec/wiki/Ops) I'm reminded that requiring the use of a single connection for HTTP/2 ("Clients SHOULD NOT open more than one HTTP/2 connection") still makes no sense to me. Due to multiplexing, HTTP/2 will naturally use FEWER connections than HTTP/1, which is a good thing, but requiring a single connection has the following drawbacks:

Servers must keep open idle connections, making load balancing more complex and creating DOS vulnerability.
Servers must turn off tcp_slow_start_after_idle in order for browsers to get good performance, again creating DOS vulnerability.
The number of simultaneous GET requests I'm able to upload in the first round trip is limited to the compressed amount that can fit in a single initcwnd. Yes compression helps with this but if I use multiple connections I will get the benefit of compression for the requests on the same connection, in addition to having multiple initcwnds!
The amount of data I'm able to download in the first round trip is limited to the amount that can fit in a single initcwnd.
Head of line blocking is exacerbated by putting all objects on a single connection.

Multiple short-lived HTTP/2 connections gives us all the performance benefits of multiplexing without any of the operational or performance drawbacks. As a proxy and a browser implementor, I plan to use multiple HTTP/2 connections when talking to HTTP/2 servers because it seems like the right thing to do from a performance, security, and operational perspective.

I know it's very late to ask this but can we remove the "SHOULD NOT" statement from the spec? Or, maybe soften it a little for those of us who cannot understand why it's there?

Thanks,

Peter