There seems to be a lot of Engineering practices you need to understand and follow to use GraphQL effectively which makes me naturally suspicious of the technology. I do judge technologies for most use cases (not niche) by how easy it is to shoot yourself in the foot - the easier it is the less I rate the technology for broad usage.

The article assumes simple schemas as well - a parent with many child relationships in this article could lead to some complex resolvers. Unless I misunderstand the article many of the strategies here are in ORMs (e.g. lazy subselects) which often don't perform as well as a crafted query given the still multiple roundtrip's to the db. They also require more code, and exhibit branching which means that performance is a function of the users query. If you know your user that's fine, but then again I don't see the advantage vs a straight REST or RPC call which would result in simpler code anyhow. It seems to work IMO in cases I guess when service isn't critical, your model/schema is simple, or you prefer flexibility of data access over reliability/predictability.