While catting actual random data is contrived, using ssh is not. What if the connection is broken while you're in vi. Vi switches to the alternate screen and then scrolling stops working. If you don't know what happened it's not clear why. How can ssh fix this other than acting like tmux and parsing every terminal command sequence? I'm not convinced there is a simple fix.
This doesn't even get into encoding issues. Some UTF-8 sequences are terminal commands. The UTF-8 encoding for U+00DF (the German eszett) contains a sequence which will cause some terminals to wait for a termination byte you wont ever send.
Plan 9 had the right idea: do away with terminal command sequences altogether. But that only works there because you can take your "terminal" and turn it into a GUI window.
- cat /dev/urandom (cat can't reasonably tell if you've piped to another command that expects raw binary data or a terminal that expects to be left in a sane state)
- ssh remotehost cat /dev/urandom (ditto)
- Emergency exit to avoid data loss when detecting e.g. memory corruption (lesser evil)
- Hardware bugs/failures erroneously emitting escape codes (memory bit flips, loose RS-232 connections)
You're of course correct that the vastly preferred thing to do when practical is to clean up when reasonable to do so - and it's probably reasonable to do so.