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.
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.