The funny thing is fast terminal rendering was a solved issue as far back as the mid 80's even on machines like the Amiga.
Yet people seem intent on inventing slow ways of doing it that then gets people to reinvent all kinds of complex ways of making it faster.
The performance differences between different terminals are indeed absolutely astounding (but rarely matters much, because the things that are much faster/slower are things you rarely do on purpose, like dumping thousands of lines to the terminal at once)
I suppose that terminals like Gnome's [0] are slow or feel "jittery" (i.e. inconsistent latency) for example because everything needs to go through a separate terminal server process. Then, there is Desktop compositing in the way. There might even be latency added by GPU acceleration (handling double buffering badly vs naively sending pixel updates to the Display Server?). Then, vector fonts are just terrible for programming on normal [1] displays - either anti-aliased (mushy, eye-straining) or not (jagged-y).
Another issue is historically bad / incompatible VT-100 emulation. I don't know what it is and I'm not a fetishist for organically grown terminal cruft, but in any case I've always had the most trouble with Gnome and KDE (missing characters, wrong colors, wrong drawing positions) while xterm works just fine, only the occasional "tput reset" needed after dumping binary data.
[0] just talking experiences, I'm probably referring to something based on VTE? Don't use Gnome regularly.
[1] "normal" meaning sub-4k / ~100dpi, soon will have to be referred to as "older"
Yet people seem intent on inventing slow ways of doing it that then gets people to reinvent all kinds of complex ways of making it faster.
The performance differences between different terminals are indeed absolutely astounding (but rarely matters much, because the things that are much faster/slower are things you rarely do on purpose, like dumping thousands of lines to the terminal at once)