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.
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.