Note that I'm not knowledgeable about those games specifically, so I can only answer in the general sense.
A lot of modern games do both game state synchronization and event delivery to some degree. Each approach has a different use-case, as Anomalous Underdog pointed out.
One advantage of the sync-the-world model is that you can reuse the general state sync code to allow new clients to jump into the game and know what's going on; the server just notes that the state delta is "everything" and sends the whole state down. With an event model, new clients must be specially handled to ensure that all necessary object-creation events are sent on connection in order to get the client up to the current game state.
Another advantage is that creation messages are less important and for some games destruction is unimportant. You don't need to send an explicit "create object X" message and ensure it is handled before any movement messages since I can just create the object when I get a movement message for it. Destruction is still a little complicated, since you need to know the difference between "object X is gone" and "object X has no more updates." Some games's gameplay requires a relatively small set of always-around synced objects so destruction is unimportant.
A pure event model is how many games are implemented at the low-level but some of those events are "here's some new state." Some sync individual object states rather than a whole game state. The advantage of this model is that it's just easier to do with partial ordering of states, non-state-based messages (like chat), control flow, and so on. With the game state model, it's important to have an additional means to send reliable events, so you're still implementing the entire event model anyway.
You can combine both methods, using state sync to handle objects that the server and client both know about, and using events for object creation, destruction, and non-state updates. This tends to be where many higher-end games go, as sending an individual state event for each object uses more bandwidth in event framing/headers, but events are needed no matter what. That rarely matters for smaller games or games that don't try really hard to fit into lower bandwidth requirements.
Note that pure state deltas in either model is a huge chore unless every update is ordererd and reliable (e.g. via TCP). The server needs to know which state the client has in order to calculate deltas appropriately. That gets hard because even if the client ACKs a packet a new state delta might be sent before the ACK is received so the client sees extra movement (once from the first packet and then that movement reapplied in the second). The server could keep a state sequence number that is sent with each update and the client can keep recent states for each sequence; the server sends which state sequence it thinks the client has and the client ignores updates if its state sequence doesn't match the packet but then you might needlessly drop some state updates that are accumulated together (eg if a packet has updates from state 5 to 7 but the client is on state 6 from a previous update whose ACK is delayed/lost then the new packet must be thrown away and the update to state 7 from 6 must be resent in another packet). That approach works for lock-step games but is still not ideal.
Using current state updates rather than deltas makes it so that missing intermediary states or duplicated state updates are irrelevant whether they come in the form of state syncs or individual events (you'll still need a proper retry and ordering mechanism for some events but not entire packets).
For a simple two-player game that has little going on besides maze navigation state sync might be easier. Just send the player's positions/orientations and the positions of any movable maze elements with each packet, append any reliable events like chat, and resend those events if their packet doesn't get ACK'd. With a pure event model you'll need to handle a lot more resend and flow-control logic for events and, if things are moving a lot, you'll just be sending an event for each object anyway so you're still doing a game state sync.
Or just use TCP; honesty for most hobbyist/student games or even AAA games that don't have a lot of real-timey requirements for action TCP is easier and works just fine (if you turn off Nagle). An increasing number of network-centric games these days use TCP (MMOs, RTSes, RPGs, etc.) but very twitchy/action-y games should still usually aim for UDP to have better latency control. Your game may will work perfectly fine with TCP which simplifies everything by making all messages reliable and ordered.