Great feedback, thanks!
In my limited experience the main reason to migrate away from publish/subscribe has been server cost and complexity (due to the implicit nature of the pubsub & reactivity).
I’ve been able to drop server costs from around $100 a month to $7 by swapping out publish/subscribe for Meteor methods. At the time I was using local minimongo collections to insert data returned by the method (and therefore providing Blaze reactivity on change). I imagine performance gains will be very slightly better with GraphQL (lack of websocket overhead).
Complexity is a key factor for maintainability. If you install several packages that are all using publications it’s very easy to end up with a mess that’s hard to trace data flowing in and out. Before you know it things slow down because it’s hard to determine what to is extraneous.
Ideally starting from scratch I would use pub/sub for things that need to be real-time reactive (say chats) and other things can use Apollo to long poll every X seconds/minutes. Then for server data use Apollo and try to skip Redux for local state unless you need it. Since it’s a dep. on Apollo (currently) it’s not too much extra effort to use it to track the state of a modal or something that needs to share global state with other things. I think a lot of people forget that the local React
setState still works great Having data containers helps cleanup that local state as well.
For existing apps if you’re having issues with state unexpectedly changing, or not updating when you expect, migrating to something more structured could help. Response time is another one… if it takes a long time to get a subscription perhaps Apollo could help. I agree with @sashko on not migrating unless you have an issue.
That’s just my preference though!