Except because of latency, it's like taking turns when you may be ahead of other players in turns or behind other players and the game does rollbacks to make the turns make sense once they've all arrived and how many turns ahead/behind you are is also dynamic.
It ends up having a very real affect on the actual game mechanics. In CS:GO a player peaking out from an obstacle has the advantage over the player waiting for them to pop out.
Anyway. I only have unfinished attempts at low-latency netcode and rollback, so can't say I'm speaking from solid experience. But I would doubt that engines implement rollback netcode for you. Essentially the game needs to be structured in a way to accomodate storage of game state as snapshots. And it needs to decide how to incorporate messages that arrive late.
The comment was that (surprisingly) all games are single threaded and feel very turn based. Even real-time games.
I also don't know what you mean by "games are single threaded and feel very turn based". Games are usually not single threaded (insofar as most games run on multiple OS threads). If you want to say they feel single threaded, then it might be because the screen emits one frame after another, and you can influence the next frame by your action? But I don't know how that is an interesting insight and it doesn't seem to have anything to do with how games stay in sync.
You might have something interesting to say, but I wasn't able to learn anything from your post. Add to that the slightly accusing tone of it ("again conflating") I can't help but be annoyed.
But anyway, this is like the most basic insight and doesn't touch what I said at all. It does not explain how games stay in sync, unless you go back to shitty 90's lockstep netcode.
As I said in my first comment.