A little more detail, as I've been doing some optimization work lately.
The draw loop and physics loops are already pretty well decoupled from other stuff in Unity. Physics actually runs multithreaded natively. Just as you suggest, I run all gameplay code including AI on a fixed timer, adjusted by game speed, while the draw loop runs as fast as the machine can handle. Unfortunately you can't just split some of your Unity objects off into different cores -- all the scripts run on the main thread.
Unity does have a Jobs system for performing multithreaded tasks. The trouble with applying it to NeuraQuarium is that (a) multithreaded Jobs cannot access objects on the main thread -- all relevant data must be copied and sent as raw values (b) the costliest calculations in the simulation involve large areas of the world -- all the objects in a Critter's visual field, with all of the properties used to process those objects into visual stimulus; or the set of all regions that contain a given scent; etc. Essentially, even if I were to convert some of these processes to multithreaded jobs it's not clear that the speed from using more cores would offset the cost of copying very large amounts of information back and forth hundreds of times.
I'm not done experimenting, though. Time will tell!