Good question but the answer is quite unknown at the moment.
In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.
In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.
But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.
Diagram:
Current:
0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]
Proposed:
0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]
I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.
I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.
The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times
Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times.
But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.