First I dont know what table you are looking at, but its 54MB/s vs 24 MB/s on average across different data types. That's a factor of 2. Aka half the throughput. I dont know what kind of performance engineering you do, but a halving of throughput is a pretty serious performance regression where I come from.

Also, latency is not a direct function of throughput. The two are separate. In this case the latency will come because when you have tmux in the middle it means your command line program writes to a pipe, which is a buffer in the kernel. tmux then has to read from that pipe, then it has to process that byte updating its internal state, then it has to generate the output bytes based on the internal state, those output bytes are written to another pipe, and finally the terminal reads from that second pipe.

There is a whole extra pipe with associated context switches for every byte (or more accurately every packet since reads/writes on a pipe are buffered). This will add latency for example for every keystroke no matter what the throughput numbers are. A pipe operation requires a poll on the pipe fd which is a context switch. Apart from whatever internal processing tmux does, there are four extra context switches added for every keystroke + response.