Once cat is spawned, the shell gets out of the way, and has nothing to do with it. (Exception: zsh will "helpfully" insert itself with `tee`-like operation in certain situations.)
What `cat` doesn't do is finding an optimal block size for writes. It does a good job of finding optimal block size for reads, but not for writes. Many older block devices perform very poorly when the write block size is not optimal.
As an example of what I was referring to, in zsh, this
a >&2 | b
a | tee /dev/stderr | b
That is, zsh inserted itself into the middle of the pipeline. There are two pipes instead of one; zsh/tee reads from the a pipe, and then writes that data to the b pipe (and stderr). This does hurt performance.
-> % python test.py 2>&1 | python test.py
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
[snip]
python 24150 someone 0u CHR 136,0 0t0 3 /dev/pts/0
python 24150 someone 1w FIFO 0,8 0t0 72772851 pipe
python 24150 someone 2w FIFO 0,8 0t0 72772851 pipe
python 24150 someone 3w CHR 5,0 0t0 1049 /dev/tty
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
[snip]
python 24151 someone 0r FIFO 0,8 0t0 72772851 pipe
python 24151 someone 1u CHR 136,0 0t0 3 /dev/pts/0
python 24151 someone 2u CHR 136,0 0t0 3 /dev/pts/0
python 24151 someone 3w CHR 5,0 0t0 1049 /dev/tty
someone@arch-two [01:29:00] [~]
-> % echo $ZSH_VERSION
5.2
someone@arch-two [01:29:16] [~]
-> % cat test.py
import os
import sys
import subprocess
with open("/dev/tty", "w") as f:
subprocess.check_call(["lsof", "-p", str(os.getpid())], stdout=f)
It's not particularly surprising that the zsh behavior is different than bash; zsh redirections are only Bourne shell-like in simple cases.
I dislike zsh's behavior because it isn't what the user typed. It should be simple to look at a command line and see how many pipes it makes; see the processes that will be involved in the pipeline. Zsh's behavior seems to me to be clever and implicit; I'd much rather have dumb and explicit.