To use a metaphor - would the world (the real world - i.e. planet Earth) stop spinning if suddenly all of its "users" (the human beings and other inhabitants) suddenly died or boarded a spaceship to migrate to another planet? No, of course not! The world would carry on spinning until the end of the universe.
If you're looking at implementing a persistent real-time simulation (a.k.a. "world"), then your world should also keep on spinning/ticking regardless of how many inhabitants (clients/users) are currently in that world.
How you keep the clients in-sync with your world is more a matter of how much data each client actually needs and cares about; including how frequently you expect that data to become stale, and whether it even matters to the client that the data may be stale. (Consider: if a tree falls in a forest, and there's nobody to hear it fall, does it still make a sound? Does anyone even care that the tree has fallen? Schrodinger doesn't care about his cat either).
Whether you choose a notification model, a streaming/broadcast model, or a request-reply model depends on what kind of data is being exchanged. You will probably find a use for all of those messaging patterns and more.
To use the real-world metaphor again, consider how much information each inhabitant of Earth gets to receive, out of all the billions of things which are happening at any one time.
An "inhabitant" sitting in a house might receive a news report (a newspaper) once per day, because newspapers only change once per day. However, when the newspaper is delivered, it's a fairly comprehensive "snapshot" of all news which has happened around them.
Then consider that same inhabitant receiving news reports on a TV; however the inhabitant only receives those reports when the TV is switched on (and the inhabitant decides when to switch on the TV, and when to switch off again). The TV station always broadcasts, without knowing who is watching. The inhabitant only watches when they choose; the broadcast doesn't go away just because they switch off the TV however.
This is analogous to having a constant 'stream' of micro-update messages broadcast in real time from a server, but client applications choosing to enable/disable their subscription to those message streams, depending on whether the client wants/needs to know at the time.
Finally, consider the case where the inhabitant has asked for specific kinds of news updates to be sent by e-mail (maybe those about Politics and Sport, but not about Health or Technology); there may be infrequent and unpredictable news reports sent at totally arbitrary times during the day; sometimes there might be 5 stories an hour, other times there may be no stories for several hours. Each notification is an update that the inhabitant has asked to be notified about because it's relevant to them. The reports about Health and Technology will not be sent to them even when those reports are published.
Overall - there is no right or wrong answer with regards to messaging patterns to synchronise client/server data; different types of data will have different requirements, and you need to choose whichever is most appropriate.