As I understand, Update() Gets picked up by reflection on initialization.
Would it matter to have one big update, from which everything in game gets updated, or have 100-1000 separate Update() in different scripts. I am talking strictly from optimization and speed perspective, code management or readability is not important here.
Using one big Update instead of many small ones is, in my opinion, a bad design decision.
You may save a few thousands ticks per frame which is meaningless. On the other hand you lose the point of components.
A class should be doing only what it is meant to do but does it all. Now you want to go for a class that will also take care of all other classes on top of its own purpose. Not only it makes debugging a pain but also it means that your classes are not highly reusable.
The point is that you should design your classes so that you can reuse them with little or no added code. Think of Unity factory components, you drag them and they run, if they would all depend on a big Update, you would always need to use that big update or add some code somewhere. This is where you are heading.
So, my advice, keep everything where it belongs and avoid this God class that is aware of all others and controls them all.
Yes you will save some ticks but you should not consider them over good code.
This isn’t an answer but comments were closed.
be warned… true lockstep networking behaves VERY badly under situations of significant uneven latency. (AKA the internet)