I've only now had time to read the whole thing, but, it's a very interesting article. I liked that it went into a lot of detail, including stuff like keyboard input lag and monitor latency - although those are more of an aside that normally only twitch gamers know and care about.
But the core of the article is about IDE latency, and I like the focus that it puts on making sure there is a smooth typing experience. This should be a design principle in the back of the mind of anyone who is working on a IDE. Personally I never felt any issue with typing in Eclipse, but I work on Windows (and actually with classic theme), which according to the benchmark actually has pretty good latency, so that matches with my experience. It only gets worse in Linux.
It could be interesting, especially on Linux, to run the benchmark tool on just an SWT Text snippet, just to see how much delay is just due to the SWT widgets (and possibly the Window Manager/Compositor), as opposed to delay incurred by Eclipse itself. Then again with all the issues Eclipse has been having on Linux and GTK3, it might be far from the list of important things to work on.
By the way, the importance of having a smooth UI typing experience is why, when I was writing the on-the-fly/asynchronous auto-save (
https://git.eclipse.org/r/#/c/68546/), I had to make sure the UI performance would not be affected, that no significant UI delays would be introduced. That's why the patch is a bit complicated, as the save work which is normally done in UI thread, has to be offloaded to a background thread. And the standard buffer dirty state listeners can't be notified on that background thread, because they might expect to be run in the UI thread. But the notifications can't be posted to the UI thread either (with asyncExec for example), because there is no knowing how long they will take. And it would not be okay to be posting these events on nearly every keystroke.