ssh in its normal interactive-session mode forwards all characters (except its escape, usually ~) to the remote host, including ^S ^Q. (Anything at the far end of a SSH/TCP/IP connection is 'remote' for this purpose, even localhost/loopback or virtual-LAN.) If you have a 'long' (propagation delay) and/or 'fat' (bandwidth) pipe -- and loopback is definitely fat -- the amount of data that can be in-flight to you before the remote host receives and acts on ^S is probably more than a VT100 can buffer, since it was designed back in the days when connection was an actual piece of wire less than 50' for RS-232, or a direct-modulation one-bit-at-a-time modem like 103 or 212A.
If you use ssh with arguments to run a command on the remote host (not an interactive session) then the terminal handling (and ^S ^Q) remains in the local OS, which should respond fast enough. Obviously this constrains the interaction you can do with the remote host(s). By default it also does SSH overhead (keyexchange and authentication) for each command, which can be costlier and slower, but with non-ancient versions you can set up a master process with -M which shares the transport (and transport setup cost) over multiple worker processes.
The only other solution I see is to not run remote things that produce too much output too fast; for example, pipe things into more or less or similar, maybe even with LINES set to less than 24. Or write large output to a temp file and browse it with vi or similar.
