Actually, I tried when you suggested it and was not able to reproduce, which only confirmed my disbelief. It does not wake at all after 15 seconds, does not send any traffic. Which is what I'd expect considering the behavior with other daemons.
It does not terminate the connection when I wake it up manually but I presume that's because sshd is using a monotonic clock (which does not advance while suspended). Effectively, not only is the SbJ not waking up, but when it eventually does (e.g. because of power btn or network traffic) for the sshd daemon only a second or two will have passed, so it won't send the keep alive.

The attached screenshot shows a capture of the traffic generated with ClientAliveInterval = 5, ClientAliveCountMax = 3. .1.13 is the Sbj while .1.3 is a workstation. It sends the first few keepalives correctly (every 5 seconds) until screen blanks, and it immediately suspends, missing the keep alive at t=15. At that point, things go random/downhill. It spent more than 5 minutes with no traffic at all after t=192 (I had to stop capturing).

I suggest you verify with a network sniffer to check what is going on.

Note that you can simulate a similar behavior to what you want by manually patching the SSH server to use wakelocks (this is similar to what several Android forks do). But the builtin SSHD does certainly not do this.
(And besides, that is still problematic as the moment you logout everything you were doing stops).