As was noted by @sjdorst above, one has to be very careful to distinguish between interactive model building/editing and rendering.
Rendering involves two crucial facts: First, it does not modify the items being rendered; the model database must be frozen during the render. Second, the effects of illumination are inherently additive and order-free. That means that you can calculate how any particular part of the model appears by dealing separately and in any order with each thing that casts light on it, and can simply add up them up. These facts make it possible to break rendering up into a collection of independent calculations that can all run at the same time, that is, to multi-thread the rendering application. And, in fact, many renderers are multi-threaded and will use multiple CPU cores if available.
Neither of these facts applies to interactive model building and editing! The whole idea is for the user to modify the model’s contents. The effects of modifications are not additive and are order-dependent. The user relies on a correct presentation of the model on the view to guide his edits; no other thread can be manipulating the model at the same time else the user will experience complete chaos!
There are a few tasks, such as saving a file, that could potentially be split off into separate threads. That might avoid freezing SU while a save is taking place. But to do so the app would still have to freeze while making a copy of the model database in memory because the save can’t happen if the user might modify something that has already been saved! The copy would temporarily double SU’s model memory requirement, which of itself might cause problems. Also, because modern OS’s all cache data and run separate OS threads for disk writes, it is unclear how much of an improvement there would be. That is, how does the time for copying in application memory and the again copying to the OS memory compare with just copying to the OS memory? I don’t know the answer, I only know it isn’t a simple question.