I don't think you need a complex threading model. The browser showed that you can get good interaction with single-threaded environment as long as you 1) can offload computation to other processes (web services, in the case of the browser, or more recently, workers) through message-passing and 2) such interaction can be performed asynchronously (i.e. while you wait for the result you can continue with the rest).
I think such kind of approach could be adopted by emacs without having to rewrite everything from scratch. Taking advantage of this would require of course rewriting a good amount of code (both elisp and C), but it could be done bit by bit over the course of a long time.
I think the Stylo developments show that it's not entirely true. Yes, you can get good performance from single-threaded models, and you can get better performance with threading. I'm also a huge advocate of not rewriting things, which is why Rust's C interop allows for incremental re-development of legacy codebases in a reasonable way.
Indeed. I think mrighele is talking about server side web app performance, which is a much higher level game and because a lot is stateless allows scale-out + loadbalancing to achieve resource utilization maximization.
When writing hi-perf systems (like a browser), this is a very different game. In this game threading is a tool you need to make sure all cores utilized.
I think such kind of approach could be adopted by emacs without having to rewrite everything from scratch. Taking advantage of this would require of course rewriting a good amount of code (both elisp and C), but it could be done bit by bit over the course of a long time.