This isn't a problem when the primary request is dynamic and served from one server/domain/connection and the remaining requests are for static assets stored on and served from another server/domain/connection.
Consider if the client makes a large POST followed by a few GETs. If the client has little upload bandwidth, the GETs will be delayed until the POST completes. With SPDY, they all can proceed concurrently. Similarly, if the client makes 5 GET requests, with the first being a heavy/slow/expensive resource for the server, the cheap resources can't be delivered until the slow resource finally is computed and returned.
Yes, that's the reason that SPDY exists, but my point is that that's actually a rare implementation in the real world. As was said elsewhere in this thread, and what I was saying, is that the most likely implementation is that one request goes to, say, www.example.com, which serves a single HTML file, and remaining requests for resources that that HTML references go to outsourced-cdn.example.com. So it's actually more important to have pipelining and SPDY support on outsourced-cdn.example.com than it is on www.example.com. That is, chances are you don't need to worry about it, that's why you pay outsourced-cdn to. There is less of a need for multiple simultaneous requests when you have good client-side caching of resources too. The usefulness of multiplexed requests is negated if you only serve one request.
The above has been the exact case at a number of companies I've worked at.
Sites and companies like Google or Facebook, that serve all their own traffic, it becomes more important for.