GraphQL is always POST, no? It's not REST at all. It's not quite RPC either. There's a single handler for all API requests. I don't know if there's a name for this type of thing.
GraphQL is a query language. It's protocol-independent. It just so happens that HTTP POST is a convenient way to deliver queries. Instead of using an HTTP endpoint, you could just as correctly implement GraphQL directly over TCP, or messaging queues, or whatever you want.
True, but when implementing GraphQL on top of webserver (like Express.js in article), correct HTTP methods should be adopted - GET for querying, POST for mutations. I don't see any harm in doing that.
I think given the current state of the spec that's pretty accurate. However we really view GraphQL as the way that front-ends/client specify their data requirements. One way of fulfilling that is to dispatch the queries to the server as is. However if you view this as an API to data, which can include client software, this can get a lot more interesting, and allows you to use different transports, messaging protocols, etc
For example on iOS we used GraphQL to transition our persistence from Core Data to a propriety (client) storage engine.