I'm curious what makes you so sure those plugins will actually use multithreading appropriately? Emacs already has methods to communicate with processes off the main thread, right?
So some of this stuff is "communicate with an external process", and I feel like many things in that space do the right thing (if only because if you don't it's immediately visible).
I have a lot of issues with "pure elisp" plugins though. Things where these plugins are doing a lot of string munging, and it's fast in testing because the tests aren't that big. But you can easily hit some edge case where suddenly you're looking for occurrences of `e` in Moby Dick so now each letter press takes a second (fortunately computers are still fast!)
If completion frameworks were async-by-default, at least that stuff wouldn't hang everything for me. At least that's my theory.
Makes sense. Auto complete things are increasingly using language servers, such that I would think they should be in the "communicate with an external process" category. Right?
For pure elisp, the worst I have seen have been around gigantic org buffers. Which, isn't too hard to split up into smaller buffers.
By far the worst case of slowdown is in gigantic log files with absurdly long lines. They made a lot of headway there in detecting the case, as I recall. I also don't think anyone ever said multithreaded would help there.