This is a very broad and unspecified question, with a simple answer that is whatever gets results on screen is the correct approach.
To elaborate on that, I'll quote David Aldridge on his excellent talk I Shot You First: Networking the Gameplay of Halo: Reach
What is gameplay networking?
Technology to help multiple players sustain the belief that they are playing a fun game together.
This is a relevant statement because if focuses us on the emphatic part of networked gameplay. In other words - it's not about perfectly synchronizing a complex state between networked machines, but maintaining a perception of synchronicity and fun between multiple players.
If we were to describe the optimal state of a multiplayer game system from a technical perspective it would be a system that replicates state perfectly, which updates at an interactive framerate with no latency across multiple machines. This is a borderline impossible problem to solve.
Like all impossible problems, when it comes to games, the solution is to fake it until it feels right. This means that any one specific solution needs to be derived from the gameplay itself and not the technology backing it.
To circle back to your question with some concrete discussion points:
- Sending game events or game actions imply some form of reliable transmission - if such message is not received by a client his simulation state goes out of sync.
- Sending state snapshots of the game world are much more fault tolerant because if you miss one update, you'll get the data on the next update and "catch up".
- The decision on the communication protocol itself is a major deciding factor in how to architect a solution - a browser game might have limited access to unreliable channels, a slower game might be easier to implement using reliable channels. In general on the opposite side of the reliability scale is delivery time - your choice is in the range of slow and reliable to fast without guarantees.
In reality most solutions would either use a reliable only channel for slower paced games, since the implementation overhead is substantially lower - or a mix of reliable and unreliable channels and a mix of state synchronization and event notifications.
For example - player position can be sent every frame as a state snapshot on an unreliable channel since we expect that state to change frequently while chat messages can be sent through a reliable channel since we only expect each unique message to manifest once, and it's not a time sensitive piece of information.
I realize this is a very long winded way of repeating my original answer of "whatever works works" - but I feel the core question was conceptual and not concrete and I hope I've given you some pointers to unpack it a bit more on your own.
One final and more pragmatic note - since you specifically mention ECS - one of the key benefits of ECS to networking is the fact that world state is very easily serializable. I would start by simply throwing the entire world state into a message and render it on the remote machine. This approach will most likely not work at scale but it will get you up and running very quickly - at which point it will float all the issues and allow you to solve and optimize domain specific problems:
- Game state to big? Figure out which data can be inferred and which data must be explicitly sent. Find a way to compress the data for transmission.
- Game feels unresponsive on a client? Look into client-side prediction and reconciliation (assuming you have server authority), Do distributed simulation if you have a PvE game where each player can claim ownership on entities he's interacting with