Their comment about packet loss makes no sense. In either HTTP pipelining or SPDY, a lost packet stalls the TCP stream... there is nothing SPDY can do to stop that. Now reordering response frames, i.e. images vs a long running cgi page, is clearly a good idea compared to http pipelining.
I like their 'everything is a lowercase key property bag' concept for requests. I don't like the multiple ways to shutdown a stream (set a flag, or send a 0 length frame). That part of the spec needs pruning.
HTTP pipelining does suck for proxies. (I develop one). I ended up supporting it from the client but I don't pipeline up to the server for compatibility, management, and giving myself a headache reasons. It's most annoying because certain magic error codes or conditions kill the whole pipeline connection and you have to start over. Also, for management simply asking what are the current connections and their requests gets more complicated since its many to many... of course with SPDY SSL the proxies won't even know what requests are occuring underneath so in that case it's simpler :)
I also don't know how they figure a server push function doesn't change HTTP/Ajax level apis... sounds like a brand new api to me.