These steps You mention are most likely done in separate engines. It is just that simple game engines usually have them in one pass. Your sequence
for each object
do physics
do game logic
draw
becomes
call physics subsystem
call game logic subsystem
call drawing subsystem
Physics Engine takes care of positions and sizes.
Game Logic Engine takes care of interpreting what Physics Engine changed (he could obstruct some waypoints ...), what goals characters have and what behaviour they should be doing, he runs scheduled scripts (this think function).
Drawing Engine draws what objects are visible, and he knows what objects are visible because Quake engines kind of cheat here (see Draw section).
My advice to You is to rather study how simulations are done rather that game engines. There is a huge pop-culture relating game development and game engines are made in imperative languages (because of tradition&speed); so it was more enlightening to me to get good textbooks (rather theory) and THEN look at engines (practice) rather than look at engines and puzzle for hours how they did it.
Physics
Whole notion of iterate all entities and do {think, draw} will probably lead to problems. There will be conflicts and so on. I belive Valve have Havok and I guess Havok takes care of enough-correct physics.
Think
Think function is run when a time in a game equals time in nextthink. It works this way in Quake engine, and Quake engine is basis for Half Life engines. It is NOT run every time.
Internally it should be a simple iterating through a list of entities and checking if time has passed to call think function. Time complexity will be O(N), where N is number of entities.
If there is a very large number of entities You should measure how much it will improve the fps. Note, that because of Amdahl's law it is potentially invisible speedup. I mean, You just iterate trough all items and decrease&check one number.
I would speed it up by sorting entities by nextthink (create list of pointers to entities and sort it each time; not array of entities, because entities might change their nextthink anytime, so rearanging them in array takes O(N) instead of O(1) in list).
You should also look at O(1) scheduler in Linux.
Draw
Engine draws what is approximately visible from area at which is camera. Game level is partition into a tree, and a area is leaf of that tree. I won't bother You with details about it... So if an entity is visible it is put into a set of visible entities and they are drawn.
They store what areas are potentially visible areas. It is called "potentialy visible set", PVS for short. There is visualisation of PVS, green capsule is player and around him is rendered what his PVS contains.
<some commercial engine>
does it? \$\endgroup\$