This is probably an instance of the DWIM principle. You want this tool to do a thing when you invoke it a certain way, but its objectives and methods differ from yours, so despite best intentions on both sides, you end up with unexpected behavior.

Argument parsing, whitespace detection, tokenizing a string, these are really difficult things even when a remote host is not involved. Try writing a shell script that always handles variables so perfectly that you can access any pathname in the filesystem, whether it has spaces, tabs, unprintables, Unicode, or whatever.

There are, of course, solutions, or at least workarounds to this. ssh can be configured on the receiving side so that it runs a particular command, and parsing whitespace/arguments should be significantly easier when you configure it this way. Alternatively, you could write custom Bash or Python to do what you want, and just have that tool on the receiving end. (The latter assumption is easier said than done!)

Configuring ssh to run a dedicated command line is probably an underutilized, underrated mode of operation. I used it to safely operate LAN backups: I had a client machine that would ssh in to a special user account, which had no actual shell, but immediately kicked off the backup process. That's the stereotypical use.

But for ad hoc use cases, like this blogger was probably trying to implement, you don't really have a chance to pre-populate the receivers with scripts or special configurations. And yeah, that becomes a pain when you're trying to do a clever one-liner and it chokes. I feel your pain. (Have you considered improvising a Python or Perl one-liner for ssh to run?)