Aside of the lacking availability of stable servers, another issue is that SPDY runs over SSL exclusively. That means that due to XP's lack of support of SNI, it's still not possible to do name-based virtual hosting.
Wasting an ip address for smaller sites is not always opportune or even possible, especially as we are running out of IP addresses.
whatever stack you're using, it probably doesn't have very stable support yet. afaik there is no SPDY for nginx, the apache module seems quite experimental, etc..
So, unless you have the chops to fix issues when they come up, you may want to wait a bit until things mature.
nginx support is in the works and I'm hoping we'll see something public in first half of this year. The apache module also got a lot of love recently, so definitely check it out.
Dev wise, probably the biggest hurdle for most people today is simply installing the latest SSL builds for NPN support (usually entails recompiling your favorite language against it as well).
The ietf draft confused me by saying spdy runs over tcp, instead of saying it runs over tls over tcp. Probably I am misreading it --- I'm out of practice at reading rfcs, and I expect it would have been all over HN if they were no longer mandating tls --- but I didn't find any language in the current draft that says it runs over tls.
Upon closer review, you're right in that it's not very clear that SPDY requires TLS. I did find this in section 5, Security Considerations:
5.3. Cross-Protocol Attacks
By utilizing TLS, we believe that SPDY introduces no new cross-
protocol attacks. TLS encrypts the contents of all transmission
(except the handshake itself), making it difficult for attackers to
control the data which could be used in a cross-protocol attack.
Also interesting is that the language in the Overview makes it seem as though TCP itself is not a requirement and that SPDY can be used over any reliable transport layer such as TCP.
RFCs generally (or at least "modern RFCs when I was paying attention", which was about a decade ago) don't like to over-specify. e.g. RFC 2068 (HTTP/1.1) includes this paragraph:
HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.
This makes clear that although you can use HTTP/1.1 over, say Unix domain sockets, and it would still work, and you could still call it HTTP/1.1, they expect it to be mostly used over TCP/IP port 80.
The language in the SPDY overview is probably the same sort of thing: making clear that they expect most usage to be over TCP, but allowing you to use something else if you really want to.
The TLS issue is probably intended to be the same thing: there's no reason why I shouldn't be able to use SPDY directly over TCP if the connection's between machines in my datacentre. But they don't make it explicit that they expect SPDY to run over TLS in normal use. Perhaps it's careless editing.
SPDY has been enabled by default in Chrome for a while.
SPDY is enabled by default in Firefox 13, currently on the nightly channel. In Firefox 11 (beta channel) or 12 (aurora channel) [2] it can be enabled with a hidden preference [3].
After Firefox 13 is released in a few months, over 40% of web users worldwide will be browsing with SPDY. (Today the number is already over 25% worldwide thanks to Chrome alone, based on numbers from StatCounter.)
Is there any reason not to support it?