A quick review of the USJ script did not turn up any variables that rely on in-game timers. I suspect that editing the GT, WT, and thread wake up timers, will provide a good test save to see if this fix might help.
I am puzzled that the game is struggling. I don't see anything in the script that would suggest a problem. I'm wondering if expanding the radius of the jumps might allow the game to discover that the player is within the correct coordinates. Modified scripts is not a good solution but might provide a few clues to where the problem lies. As long as you are experimenting with a modified main, consider adding text messages to each stage of the jump as a strategy for isolating the problem. (Added: This would probably need to be a new save test as any changes to active threads usually results in an immediate crash.)
Another strategy that might be a less destructive solution is to modify your cleo frame limiter script to detect when a unique jump is in progress and limit the frame rate to 30 FPS until the jump is complete. A quick search through the III scripts shows that the game speed is always 1.0 unless a USJ is in progress, then it is set to 0.25. You might be able to tease a jump in progress global variable out of the control variables used in the USJ thread but nothing obvious jumped out at me. In VC the gamespeed is always 1.0 except it is set to 0.3 during USJs and some parts of the Stunt Boat Challenge - I can't remember the details of this mission.
My thought is, limit the frame rate when the game speed is less than 0.33 and use the same script for both games. This strategy is based on a crude understanding of early patches for problems with dancing and lowrider challenges in the PC version of SA. If game speed is not well documented in memory then it should be easy to isolate by seeding a unique float into the time scale value in the save file.
From the GTA III Save Wiki
0x006C float time scale (opcode 051D)
I strongly suspect that the opcode listed above should be 015D: set_gamespeed 0.25, but this should probably be verified before making the correction. However, there is no opcode listed for 051D so I'm pretty confident that this is a typographical error.
I'm not sure what to suggest for the V-sync strategy.
________________________ Added Notes ________________________
Keep an eye on the globals shown below in III. Other uses of 00BF are always to $65 and $66. These two should always be read just before use. What you need to watch for are occasions where these values are recorded elsewhere. A quick search did not find anything obvious. Edit: I don't think this is an issue. IIRC, it was 01BD that is directly tied to the global timer and is the most concern for resetting the clock.
00BF: $2451 = current_time_hours, $2452 = current_time_minutes
It looks like the police trigger zones are not integrated into the engine on III or VC. Are they disabled on a save with the global and weather timers reset but the threads left asleep? Police Trigger: Usually, police shooting out of nowhere in response to the player entering a certain area with a wanted level. It's always the same number of cars in the same spot, which is different from the random spawns that escalate to Swat, FIB, and Army.
Are there other issues associated with very large global timer values in III or VC? Perhaps a timer reset strategy would have other uses. Seeding larger GT and WT values doesn't usually have the adverse effects on wake timers and timestamps that a lower value does. Seeding a unique value into the GT of a save and re-saving might make it easier to identify unknown timers. Search for the upper word in the global timer dword as the lower bits will vary.
Resetting the global and weather timers to a low value is a useful strategy for disabling all threads. I have used this strategy to isolate save problems to data file compatibility (you can basically load damn near any screwed up save), and then reset the wake timers one at a time to find a problem thread. You can kill active missions saved by little brothers using a save anywhere mod and then undo the timers to have a working save (maybe delete some blips or mission objects). If missing objects are causing a crash you can at least go to the area and look for the object.
I don't know why the repair tools tweak the local timers of active threads. My best guess is that pdescobar thought there might be problems and included this tweak in his early repair tool and everyone else followed suit without checking if it really matters. I know pdescobar to have had an over-engineer philosophy. But if you are doing manual edits you might be able to get away with skipping the local timers.
I'm going to be really busy with work for the new few weeks and I probably won't be able to contribute anything of substance. Good luck. I'm piling on the notes somewhat out of context while I've got the time.
010 Editor - It's not really all that expensive. If you are really into save editing it is an extremely powerful tool you should consider. I've barely started to learn how to use the extensive feature set. The primary reason I got the 010 Editor was to take advantage of the gta save templates produced by Seemann. These templates can break down the structure of the saves and display the information in a much more useful form. Look for links at the end of each save wiki.
$CURRENT_TIME_IN_MS = This value may be used to prevent the player from being interrupted by phone calls too quickly after a mission has ended. If it isn't reset the calls will be disabled but this can easily be fixed by triggering any mission. I may be wrong on the specific variable. I'm too tired to follow through but I know this value is hidden in SA and suspect it is included in VC and III. You should probably look for other instances of 01BD associated with global variables. Added: In SA there may be problems with eating fast food if the timers are reset within 3 hours (iirc) after eating.