The gas/heat calculations are embarrassingly parallel due to how ONI implements them. You can divide into nxm regions and there is not even a need for locking. At boundaries you can use the existing tiebreak for gas movement and it will just work. With how oni calculates you'd be adding 2-4 extra rows+columns of tile to each region's calculation depending on what you chose for n/m and that'd be the entirety of the overhead. (min 2 because they use a periodic boundary condition in the simulation, 1 if they didn't, kind of an irrelevant sidenote given you only hit the minimum if you divide into 2 regions)
Dupe scheduling is an interesting subject and would be fun to create optimized parallel & single threaded algorithms for. On the naive end, just sending batches of dupes to each thread to create individual priorities and then doing elimination on a single thread afterward should be a performance boost over what's there now. I'm not convinced that's the "correct" approach, but it seems like you'd be doing close to what's done now and just brute forcing it.
I don't think ONI is going to parallelize anything given it wasn't written with it in mind. There are far less time consuming optimizations they could do first (like in pathfinding another area I love), and given there are limited resources dedicated to the game there are far more important features/fixes to tackle.
My assumption for the DLC is they will run each asteroid in a separate thread. The easiest way to parallelize any simulation is to run multiple independent instances of your existing simulation. This assumption is because the simulations are entirely independent and the only communication between threads would be when you launch a rocket to send things between worlds. I'll be fairly surprised if they don't take this approach, because this doesn't require changes to any game systems except those that must change with the DLC to begin with.