You're right - in the scale of app-level problems, GraphQL is just a low-level protocol. It requires language-specific libs to address these higher-level problems (provide interfaces, structs, query typing, etc). As a very basic example, programatically building a GraphQL query is unnecessary complex outside of JS because many languages don't yet have a QueryBuilder for the GraphQL syntax. There are some community efforts, but as of yet no heavy corporate players to drive GraphQL-specific dev (e.g. like Pivotal/Sensio/Sencha did for their respective fields).
My company recently did (1000+ employees), though from what I've seen, many of my coworkers familiar with only svn are still using git like svn. We also have a lot of legacy code still within svn (various reasons outside of my team's control), so the transition is pretty messy IMHO.
I feel like the same thing is happening now with GraphQL versus REST. On some level it seems like GraphQL is altogether better than REST, but we don't see a mad rush to adopt GraphQL, because it represents a big shift in thinking, and those of us who just spent the last 10 years creating RESTful interfaces, we are a bit slow to throw out all of our work and start over with GraphQL. Also, the frontend needs to change as much as the backend, so it requires a full re-write of everything.
All the same, a title like "Scale vs. Node.js as a RESTful back end server" does strike me as an anachronism in 2016. Who cares? I doubt I will ever again build a RESTful interface. Rather, on the project I'm working on right now, we are getting rid of the RESTful interface and we are looking at our GraphQL options:
https://github.com/chentsulin/awesome-graphql
Is Scala or Node.js the best option for building a GraphQL server? That would be an interesting article.