They keep the discussion very high level. The topic is much deeper, but they appear to be constraining themselves to a single-timestep-state. If they loosened up the state to include two timesteps then a lot more could be parallelized. Since the simulation and graphics are in lockstep, this would add one frame of latency. One frame of latency is hardly noticeable against the 7-10 frames minimum added in multiplayer but the payoff could be massive. It’s hard work, without a doubt. An example I like to point to is the minecraft mod “tickthreading”. It was never stable, but the concept is there and sound.
It's hard to tell for sure. Double-buffering game updates like that can involve a lot of memory copying. Considering that it would not surprise me in the least if Factorio was close to being bottlenecked by memory bandwidth, this could easily be counterproductive.
Factorio is sensitive to memory latency, not memory throughout. This matches expectation of a single threaded application with many data dependencies. Ripe for multithreading where data independencies can be made.
I've always wondered, how exactly games do this. Do you have at least one "write" state and one "read" state, so that the simulation can write during its update and the renderer can read the previous state independently? I think copying the write state to the read state would probably take some time in a Factorio "gigafactory", while the renderer only has to access a tiny part of the state most of the time.
