First of all - does spiped give you an option to set TCP_KEEPALIVE on its socket? The README doesn't mention it, and if I understand correctly, unless spiped does it, the application has no way to do it either. But even if not - don't rush to add it:
TCP keepalives is the common but practically wrong answer. TCP keepalives kick in after 2 hrs (default), and I've used TCP stacks that wouldn't let you configure it to less than 60 mins. For almost any use over a fragile connection, I'd like to know the connection failed within minutes, not hours.
Just to be clear: spiped gives you the same "disconnection detection" guarantee that the underlying TCP gives you in a local network; if you have a connection to another computer, and it unexpectedly reboots / panics / shuts down, and you don't transmit anything - you'll never know the connection is dead with either a TCP connection or a spiped connection (until you try to send something, OR you've configured TCP keepalive _and_ it's been more than 2 hours).
However, with ssh using ServerAliveInterval and ClientAliveInterval settings, you'll get active detection and immediate notification when the disconnect is detected. (With ServerAliveInterval 60 and default count of 3, it'll take up to 4 minutes). autossh will also give you automatic reconnect (whether you pipe through the main shell or use -L / -R).
Using ssh's keep alive to detect connection problems is a kludge; if you really need this functionality, build it into your protocol. However, if you use it to forward a service you cannot modify (e.g. tunneling HTTP connections from browser to server), I find that it is very useful to let ssh figure out that a connection is borked, rather than wait for hours until the TCP stack of browser realizes that.
In fact, I am ashamed to admit that I've used sshuttle on a LAN just so that I get quick disconnect notifications from a computer that had kernel panics. It's ugly, but it does work.
"TCP keepalives kick in after 2 hrs (default), and I've used TCP stacks that wouldn't let you configure it to less than 60 mins."
We were doing some interoperability testing with an IEC-61850 stack, and the vendor's library, set the TCP-Keepalive to 100 milliseconds. Needless to say this caused issues on our 30 kbit links.
... which is what TCP keepalives are for.