This has to do with how Flax handles the loop event scheduling (makes it a lot faster to do it this way too). Flax does not work like most other engines. To be honest other engines should be migrating to how Flax is doing things but will take substantial work to do it.
Fun side note, BGS Creation Engine 1/2 already does this and has for a very long time.
Per the Manual.
For the Physics loop and execution order. Hard testing. I put all the math in there too.
Only in very rare cases should you (the coder) allow analysis (via code logic execution) on anything faster than 25ms. In most cases you should have a handler than does most everything on 50ms intervals (x20 per second). This is plenty fast for just about anything. Make sure to read the notes I made about Flax physics settings. Flax defaults are still not right.
This means you would have a logic handler that executes ‘scripts’ on intervals.
Sure, some things must operate on the Frame. Which frame depends on what it is and what you need to do with it (ie OnUpdate, OnLateUpdate, OnfixedUpdate…etc.). In 99% of all things done you can mostly get away with OnUpdate then the 1% that needs the interesting random behavior of Physics to release a Physics Copy of something and let it be handled by the OnFixedUpdate at Frame Loop speed. This is only very temporary and will save you a lot of headaches later.
This above philosophy works with ArchVis, FPS Shooters, Survival, Life Sims, anything really. You must build a foundational framework to make your work later easier. Flax and Unity are very easy to build this framework. UE4/5 have their own framework already and can be difficult to work within if outside of what Epic built their engine for purpose. Godot is also much harder to build a framework like this because of how the scripts are attached to their nodes.
Hope that gives some insight.