You've asked about two cases, but I think you need a third:
foo > bar
Without the background and with the background won't much matter --
bash(1) doesn't actually have to do anything with the standard input, standard output or standard error when you're executing another program.
bash(1) never even sees it. It is just waiting for the process to die, so it can give you another shell prompt.
When you run the script in the background, you'll be able to interact with your
bash(1) again very quickly, but any output will still go over your
ssh(1) channel, potentially very slowly, and potentially the
write(2) syscalls in your
ssh(1) client might block, causing the pseudo-terminal it creates to block, causing your script to block when it calls
write(2). This is all identical to the first case -- the only difference is you can type commands to your
bash(1) while the script is sending you output, and maybe
kill %1 to kill it, or start other services, or whatever. The script will run at the same speed either way.
In the third case, when you redirect output to a file, the
ssh(1) session is no longer a potential bottleneck, and thus not a potential bottleneck for the execution of your script. It can run quite quickly, perhaps much faster than even running it locally without output redirection. (Have you ever seen
top(1) output for your terminals when you've run a command that generates a lot of terminal output?)
Of course, a tool like
dtach(1)?) can also let you run a script without sending its output over the terminal session, so maybe a fourth option is required. But there's probably more ways to run a script without forcing its output to be sent over the network...