For professional developers that know more or less what they are doing, most of those things are absolute non-issues. Let's list it:

> if you expose a fully self documenting query API to all clients, you better be damn sure that every field is authorised against the current user appropriately to the context in which that field is being fetched.

The same is true for a "regular http API" [now abbreviated as "rest API"] (in case it's not clear: imagine how the http API would look like and think about if it would be somehow magically secure by default. Spoiler: it won't). Security by obscurity was never a great thing. It can help, but it's never sufficient on its own.

> Compare this to the REST world where generally speaking you would authorise every endpoint, a far smaller task.

Just think about how many endpoints you would actually need to cover all combinations that the graphql API offers.

> Rate limiting: With GraphQL we cannot assume that all requests are equally hard on the server. (...)

It's true. However: a rest API only makes that easier because it's less flexible and you have to manually create one endpoint for each of the various graphql API combinations.
So instead, a classical graphql mitigation that the author does not mention is to simply require the client (or some clients) to only use fixed (predefined) queries. That is then the same as what a rest API does, problem solved. So graphql is not worse of here, but it can be much better.

> Query parsing

This point is actually fair, except for the claim that there is no equivalent in REST. That is simply not true, as there have been many cases where rest frameworks worked with json and could be ddos'd by using large json numbers.

> Performance: When it comes to performance in GraphQL people often talk about it’s incompatibility with HTTP caching. For me personally, this has not been an issue.

Funny, because that is indeed one factual disadvantage of graphql.

> Data fetching and the N+1 problem: TLDR: if a field resolver hits an external data source such as a DB or HTTP API, and it is nested in a list containing N items, it will do those calls N times.

No, this is wrong. But first: this problem exists in a rest API as well, but worse: instead of N+1 queries to the DB, it will N+1 http requests AND N+1 db requests.
But with graphql and some libraries (or some handwritten code) it is comparibly easy to write resolvers that are smart and "gather" all requests on the same query level and then execute them in one go. This is harder to do in a http api because you definitely have to do this by hand (as the auther describes).

> GraphQL discourages breaking changes and provides no tools to deal with them.

What? Comon. In a rest API there is no means to do anything against breaking changes by default. Graphql at least comes with builtin deprecation (but not versioning though).

> Reliance on HTTP response codes turns up everywhere in tooling, so dealing with the fact that 200 can mean everything from everything is Ok through to everything is down can be quite annoying.

True, but that can be adjusted. I did that and made it so that if all queries failed due to a user-error, the request will return 400, otherwise 204 if they partly failed.

> Fetching all your data in one query in the HTTP 2+ age is often not beneficial to response time, in fact it will worsen it if your server is not parallelised

Okay, I'm starting to be snarky now: maybe choose a better language or server then, don't blame it on graphql.

And actually, many real problems of graphql don't even get mentioned. For example: graphql has no builtin map type, which is very annoying. Or, it has union types in the response, but you can't use the same types as inputs due to a lack of tagging-concept.

And so on. My conclusion: the auther is actually fairly inexperienced when it comes to graphql and they probably had a bad experience partly due to using ruby.

My own judgement: graphql is great except for very very specific cases, especially in projects that require huge amounts of servers and have a high level of stability in the API. I would always default to graphql unless the requirements speak against it.