graphql has a subscription type, but it requires some additional setup, but to be honest, i never used it because i never really needed it.
You seldom really need pub/sub (=“realtime” updates). Its nice to have and i loved that about meteor, but it comes at high costs: it makes scaling hard and you can fall into non-obvious pit-falls when you try to scale. You should consider where “realtime” updates are actually required. If you do fleet-tracking, ok, but i guess there are more specialized solutions for that. In some cases realtime-updates can also be annoying for users, e.g. in a message-board.
if you have specific cases for real-time updates, you can also consider polling (some seconds interval). It sounds inefficient, but if you expect regular updates anyway, polling actually leads to roughly the same load on network and server, it is just much simpler and therefore easier to maintain, scale and understand. Or you add a pub/sub channel for specific use cases.
On a side note: in apollo client you do get updates from mutations, optimistic responses and if multiple components fetch the same data, they will be in sync. So, everything the current user is doing, is “in sync” with the backend usually. I think that is what most would expect from “realtime updates” .
If not already clear: i also think SSR, data-hydration with pub/ssub, etc. should be part of meteor core. Many devs still use it (i also think its hard to migrate away from it, i would therefore not recommend to use it in new projects if possible, but thats my personal opinion)