Hmm. Many of these processes have to be finished every single frame. Temperature is complicated because it's not just per-tile but also every object and spatter. Stress has to be every frame too, for the most part. For things that are going to run at the beginning or end or whatever of every frame, I just don't see any value in all that expensive context switching. Plus, you potentially double your memory overhead. I'll explain:
Let's say you have one thread. It runs stress stuff, then it runs critters moving around and acting, then it runs temperature. At the beginning of each frame, it can focus entirely on stress--and if that changes the map, it can happen right away, before pathfinding and temperature care. Then, critters move, and a dragon breathes fire. At the end of the tick, that fire has some effect.
But with multiple threads...Well, let's say you're running temperature, and you just calculated the tiles right in front of the dragon. Whoops! It just breathed fire so that's not valid any more. Or, the game just decided that a bridge under one of your dwarves is now on fire. Well, that kind of messes with the action he was taking...
Of course, normally you'd say "That bridge can't burn down right now. The current temperature calculations can't take effect until next tick." But that means you gotta store the new values somewhere while you're working... Eh, there's probably a single buffer like that already, but when you have like ten threads that all need their own buffer, and then need to be recombined, it gets really ugly.
I just don't see any value in splitting up tasks that always need to run in a certan order, into different threads. Pathfinding is fine because it's not part of the WORLD--The little dwarfy AIs can pause for a little bit while making decisions, and besides, their requests are bursty in a way that physics isn't. You get nice gains when you can amortize burstiness.