Here at OkCupid, we're pretty big fans of using GraphQL. When it comes to fetching data on any of our client platforms, the abstraction that the query language provides grants the flexibility for us to fetch precisely the data that we need in each situation.
At the end of the day, GraphQL really is just that: an abstraction. The mutation, query, and subscription types abstractly model the fundamental ways in which we interact with any data. The schema serves as a contract between some source of data and its destination, and it defines what data can be queried and how it ought to be queried. The data that an incoming query outlines would be resolved by our GraphQL server instance in most cases, but the destination of that data (in our case, let's say it's a mobile app or web app acting as a client), doesn't really need to know about the source or resolution strategy of the data in question.
This is really nice, because it means that the data can come from anywhere that the GraphQL server has access to. Maybe we want to resolve our data using something in the filesystem, or maybe a local database, or maybe a remote one. Perhaps we can call some other server exposed to us, via RPC or REST or any protocol, really. Maybe our data is currently in memory somewhere and that's technically fine as well! That indifference of our datasource(s) is what allows this model, and the architecture of a data graph to be so scalable (Mandi Wise has a great video that demonstrates this while covering the concept of a federated graph).
Regardless of the source of the data, the client implementation doesn't really need to change at all, and that's crucially important to understanding the notion of using GraphQL for local state management. Imagine your application's local state: it really is just another source of data, after all, isn't it? So, then the question is, what is stopping us from leveraging the abstraction provided to us by this query language paradigm to manage this data as well?