I can only guess the paste function of my PC (xubuntu 16.04) is pushing the data too fast (the serial baud is 115200).
That assumption is wrong. The terminal driver will always write through the data from its output queue with the configured baud rate, and a
write(2) to the terminal will either return a short count, or block if there's no more space in the output queue (or instead of blocking, will return -1 and set
EAGAIN if the terminal is set in non-blocking mode). The serial driver will not "adapt" the baud rate to how much data it has to push through.
You can easily test that if you have two machines which can be connected via a serial line (or you could connect the same machine to itself, eg. 2 USB->serial adapters, two serial ports connected via a null-modem cable, etc).
/dev/ttyUSB0 on machine A is connected to
/dev/ttyUSB1 on machine B:
On machine A:
# stty -F /dev/ttyUSB0 speed 50 raw; cat /dev/ttyUSB0
On machine B:
stty -F /dev/ttyUSB1 speed 50 raw opost onlcr; cat >/dev/ttyUSB1
Now, paste some large text in the command line on machine
B, and see it nicely trickle down at the speed of ~5 characters per second on machine
The real problem is with brogrammers which ignore the exit status of
write(2) or assume that while it can return an error, it will never a return a count less than required. The solution is to fix or stop using their junk, not to use band-aids which are neither reliable nor very effective.
Also, if the cable/connections are bad/noisy, you will have to lower the baud rate, otherwise the data will turn into binary junk, and some serial-adapters may lock hard and have to be reset.
The baud rate should also be lowered if one of the devices is not able to cope with its nominal baud rate, and doesn't support any kind of hardware or software flow control (xon/xoff).