Also, in GUI space, the BeOS/Haiku app server still offers a more distributed workload compared to other desktop environments. Every windows is assigned its own thread, the app gets its own thread, and the app and application server have 1 thread per app and window to ensure they are not blocked waiting for slow app message parsing. So minimum BeOS app with graphical “Hello World” window is 4 threads. So even if the app is busy, the rest of the system still feels responsive.
All this comes at a throughput cost, as well as an app development complexity cost, especially for ported apps. Haiku needs to marshall Qt/Gtk/toolkit messages from many windows into a single message queue to prevent multithreaded bugs from popping up (since in their original environment, all app message loopers were not multithreaded). This marshalling needs additional lock/unlock calls in Haiku even when not needed (messages to same window).
Haiku native apps, on the other hand, are smooth as ice. See this screenshot of Medo video editor where all windows are working in their own threads (https://raw.githubusercontent.com/smallstepforman/Medo/refs/...). On modern systems, this app is smooth as ice, which for a video editor is heresy. Disclaimer: I wrote the linked Haiku app.