I have used urxvt, st, and Alacritty extensively and I would say that to me they feel “snappy” in exactly that order. You are of course welcome to pick whatever metric you want to judge a piece of software, but I can not say that I have ever been bothered by st’s input latency. The input handling is done using XEvent and a call to pselect in x.c and I am sure a patch that does not increase the code complexity massively would be accepted upstream.
Luu also had this to say about the experimental setup for st:
> st on macOS was running as an X client under XQuartz. To see if XQuartz is inherently slow, I tried runes, another "native" Linux terminal that uses XQuartz; runes had much better tail latency than st and iterm2.
Maybe it matters, maybe it does not. But I feel like picking your terminal comes down to a lot more than a single metric and input latency experiment.
The terminal emulator is probably the most used and most important software I'm running. It needs to be enjoyable. I personally can feel the lag so its not good enough for me.
Anyway that being said I have some collegues that are not bothered by lagging mouse cursors and other janky stuff so I can somewhat understand that this might not matter to some people.
edit:
I just tried out st again on my gnu/linux machine and it seems to be fine with respect to input latency so I guess its not all too bad of a terminal emulator. Maybe it only sucks on macOS.
It's probably what ninjin said -- XQuartz latency. I use it on Debian, and speed-wise, I can't tell the difference between st & the GPU-accelerated terminals. On Mac, I switched from iTerm2 to Apple's built-in terminal. It sips battery compared to all of the others.
[1] https://danluu.com/term-latency/