What got me thinking about these ideas were cases where having a distributed frontend felt overengineered. If you have problems where GraphQL makes sense, this would be a step in the wrong direction.
To be honest, I'd use GraphQL at any scale. I've recently used it in programming challenges for job interviews, and I've used it in production for about 18 months. It's such a good conceptual fit for front-end, that it now feels strange to work any other way.
It's more like an enhancement of the traditional backend-for-frontend (BFFs) pattern, enabling ad-hoc endpoints (based on queries) rather than static ones.
The main productivity benefit comes from the fact that the query language is a very good fit for the component model. Each component can declare its data dependencies in the form of query fragments, and these get composed into a single query for the entire UI. It means every time you use a component, you can be sure that you'll have the data you need.
I should add that none of this is a unique capability of GraphQL, I know people who've built similar component-data binding with JSON-API, but it's the full package that's compelling. The query language is lovely to work with. You can build GraphQL schemas around the needs of clients, allowing you to hide any weird data modelling or service boundaries you may have in your platform. As an API designer, as well as a front-end developer, I love it.