I'd love to hear more details how exactly to trigger such prominent flickers, as I don't notice any while using my system.
On my system, VTE (the engine behind GNOME Terminal) can process about 10 MB/s of incoming data. The performance of other emulators aren't very far away from this either, maybe within a factor of 3 or 5 in both directions. This a lot, should be more than enough for flickes-less updates.
Keep in mind though that a fullscreen terminal might contain a few tens of thousands of character cells. UTF-8 characters consist of multiple bytes. Switching to different attributes (colors, boldness etc.) requires escape sequences that can go from 3–4 to easily 10–20 bytes (especially with 256-color and truecolor extensions). Truly complex layouts can thus require 100 kB or even larger amount of traffic. This sure cannot be passed over the tty line in a single step. I'm even uncertain whether certain apps (or screen drawing libraries) care to buffer the entire output in a single step. Perhaps they just use printf() and let stdio flush them after every 8 kB or so. This could be another reason for them being somewhat slow.
I'm not really familiar with the kernel's scheduling behavior, e.g. whether it needs to toggle back and forth between the two processes as well as user/kernel modes, or whether they can run simultaneously on a multi-threaded CPU. I truly hope though that they can run simultaneously on a multi-core CPU, which most CPUs are nowadays.
There is no intentional throttling in the story. There might be guesswork, though, when emulators decide whether to continue reading data, or update their screen. For example, if the terminal emulator processes the input faster than the app emits them, it sees it stalling after processing the first chunk, and thus might reasonably decide to update its UI.
The cursor is probably the most prominent to flicker, since the cursor moves along the screen as the contents are being updated. It cannot stay at the same place. If the emulator updates its screen just once while receiving the input data, and the cursor eventually remains at the same location, this flicker most likely become visible.
You might be interested in this proposal for atomic updates (discussions here) that would mostly solve this issue, if supported by both the terminal emulator as well as the application running inside.
You might also be interested in why the scrolling experience with the keyboard is necessarily jerky due to an interference between the keyboard repeat rate and the monitor refresh rate, something that isn't flickering per se, but causes an unpleasant experience.
Best Answer
Not all of the output is cursor-addressing. Some of it is line-feeds, which will (when the cursor happens to be on the bottom row) cause the terminal to scroll up. Here's a visible rendering using
unmapof the beginning of the output: look for the\n(newlines are "line-feeds");When you use a smaller screen-size, the line-feeds that didn't cause scrolling are more likely to be on the bottom row, so you'll see it scroll up.