The script isn't being passed over ssh's stdin.

Well, meaning what value is all that adding above just:

$ cat script | ssh someserver bash

The value added is that you’re not using stdin and can use it for something else.

Whether that’s actually useful depends on the use case. Personally I have an ssh wrapper script, somewhat similar (though not using base64), that fixes the quoting so that the argv passed to the wrapper directly corresponds to the argv of the command on the remote end. It’s meant for interactive use, so the program I’m trying to run could easily be something that reads from stdin, or even an interactive program like sudo or vim that expects stdin/stdout to be a tty. (To make those work, the -t option has to be passed to ssh.)

The equivalent would be of catting the script and piping that to the (remote) bash, but as part of the SSH arguments, not its stdin.

So:

  ssh user@remotehost "$( cat script ) | bash"

Note that shell expansion of

  $( cat script )

... occurs locally, not on the remote side. This means that any interpretable elements of the output (c|w)ould also be expanded locally, though I'm not quite sure what effects this might have.

That said, I'm not clear on exactly on what base64 adds here, though as "script" is directly interpreted and translated by base64, any local shell expansion is avoided.

There's a #UselessUseOfCat as well. Method could be simplified to:

   ssh user@remotehost "$( base64 -w0 <script ) | base64 -d | bash )"

Note that the base64 encoding occurs locally, and decoding remotely, which I think then avoids expansion issues.

There's still the maximum argument length to worry about though, and that's where a script or here document might be preferred.