That's honestly not particularly clear. It doesn't say the command will be invoked by a shell on the remote host. Sure the whole "separated by spaces" thing sorta implies it will, as spaces don't mean much to anything but a shell, but it's still fairly vague.
In fact, later on the man page only mentions a shell in the part that talks about the behavior when no additional arguments are given:
When the user's identity has been accepted by the server, the server either executes the given command in a non-interactive session or, if no command has been specified, logs into the machine and gives the user a normal shell as an interactive session.
The wording "executes the given command" would generally not imply "I'll just throw it at $SHELL and see what happens".A few lines later it gets even more confusing:
The session terminates when the command or shell on the remote machine exits and all X11 and TCP connections have been closed.
...which I definitely would say suggests that either a shell is executed or the command supplied as argument to ssh. That it means "command as interpreted by a shell on the remote host" is far from obvious. > The wording "executes the given command" would generally not imply "I'll just throw it at $SHELL and see what happens".
"command" means exactly that. Evaluation by shell. With that in mind, the manual page should read less ambiguous to you.
I actually don't have a good source for that, but you can check the execve(2) manpage. If command would refer to the execution of an argument vector, it would have been mentioned in there.
The other meaning of "command" refers to specific programs like those in /bin.