Consider, for example:
   ssh localhost date >/dev/full
When ssh attempts to write the output of date (which came via the ssh connection from the server end's invocation of date), it gets ENOSPC.  However, no message is printed to stderr, and the whole invocation exits with status 0.

A similar problem arises with, for example:
  ssh localhost wc -l 0>/dev/null
Here ssh gets EBADF trying to read its own stdin.  However, it signals this to its peer as a normal channel close, and does not report the error at all.

Not reporting these kinds of errors is a problem because it can cause silent data loss.

I think that ssh should instead, when it detects a read or write error on stdin, stdout or stderr: (attempt to) print a message to stderr, and make a note that an error occurred; when the command eventually exits, it should change the exit status of the program to 255 ("an error occurred") according to the manpage.

(In theory it might be possible to extend the channel protocol to allow ssh to signal to sshd that the channel is broken.  However, there is little that sshd could do with this information, since it can't cause errors to be visible at the other ends of the pipes to its child the remote command.)

Thanks for your attention,
Ian.

Transcript demonstrating the problem, and comparing the behaviour with similar commands run locally:

mariner:~> ssh localhost date >/dev/full
mariner:~> echo $?
0
mariner:~> date >/dev/full
date: write error: No space left on device
mariner:~> echo $?
1
mariner:~> ssh localhost wc -l 0>/dev/null 
0
mariner:~> echo $?
0
mariner:~> wc -l 0>/dev/null 
wc: standard input: Bad file descriptor
0
mariner:~> echo $?
1
mariner:~>

(I'm using ssh from Debian wheezy's openssh-client 1:6.0p1-4+deb7u2 on i386.)