Because SPDY has well known flaws (let's call them design choices) for example in caching. There have been many discussions in HN about these topics.
Also, because there is no such a thing as "SPDY" what you are referring to is "SPDY 2 as implemented by Google Chrome and almost fully documented by Google". SPDY is a work in progress. If you want a real deployment to be possible, you need to have at least a fully documented basic core that has been discussed openly, not just an implementation from a corporation subject to changes whenever internal pressures require it.
Now it is, before it was not. And that is exactly my point in my reply: you cannot take whatever you call "SPDY" at the moment (implementations + wiki pages) and call it "HTTP 2". You need to document it, propose it, discuss it openly, accept criticism, fixes and, if needed, radical changes. This is what is happening now in the HTTPbis working group and is a good thing, but it is not going to be a rubber-stamping process for SPDY as it is now, I hope.
SPDY patches some of the problems in the more common use cases for HTTP for today's applications. It doesn't really change much of the spec, and it doesn't even pretend to address potential future use cases. Here's a recent criticism by the lead architect of Varnish https://news.ycombinator.com/item?id=4253538
On the other hand, SPDY never tried to address those issues: the aim was to create a more efficient over-the-wire transport layer for HTTP/1.1 semantics.
Standardization is a critical step. It verifies that we use open IP which is available to everyone, provides a open forum for discussion, and archives the protocol in a way all vendors can use to resolve disputes about how we communicate.
