The following is my personal opinion and experience, not an objective judgement on Apollo state management. Therefore, other people might legitimately have different experience and preferences. That said, the article states:
Now imagine an application fetching data from a GraphQL endpoint with Apollo client. By default, Apollo will store this data to Apollo cache. But what if we have some local application state, stored in Vuex? If we copy data from Apollo cache to Vuex, we’re doubling our data. If we leave data from the API in Apollo and local data in Vuex, there will be two sources of truth.
I disagree that having both the Apollo cache and the Vuex (or Redux, or any other state store) represents a problem. As much as I like Apollo for interacting with a GraphQL API, I find it gets quickly complex to use it for application state management. I think it makes more sense to separate application state from the query cache.
I prefer to consider the Apollo cache just a cache for the API request. I then manage application state separately. That usually leads to a more modular application, with loosely coupled components.
With a REST API, it is be totally fine to let the browser cache responses according to the cache headers, and also store in the application state whatever data is appropriate. I feel the same about the Apollo cache: I use it to speed up queries (when appropriate), but not as an application state store.
So, in short, I agree with you that the design proposed by the article is overly complex and tightly coupled. You can use both Apollo and Vuex if that feels better, and that is what I would suggest doing.