Having youtube tutorials on something does not make you an expert on the subject. He appears to not have the skills to do basic JS debugging. It's great to ask for help, everyone needs help at some point. The issue I see is starting with "The dark side of GraphQL". If you haven't found the actual issue, how do you even know what the cause is? Just because your SQL query is fast doesn't mean there is some inherent problem in GraphQL or Apollo. That argument doesn't follow. It could be user error.
I don't mean to sound like a blind witness fanboy, but I think teaching something effectively does require some mastery of the subject.
I also don't think it is hyperbolic say he doesn't have basic debugging skills. What qualifies as basic debugging skills? Like he isn't capable of using a debugger and introspecting code? He can't use a print statement and look at code? Debugging an E2E bottleneck is not trivial.
I have no doubt. The unfortunate bit is that his tweet uses "GraphQL" to refer to a specific implementation (Apollo Server) of GraphQL rather than GraphQL itself.
But Apollo Server is by far the most common implementation of GraphQL servers, and the OP's thesis based on the twitter thread is that type-checking and validation are responsible for the slowdown, and type-checking and validation are inherent to GraphQL.
But there are dark sides to using sql, often from the abstraction that sql provides.
Maybe the optimizer picks a poor plan and you can't figure out how to make it work better. Maybe the schema has redundancy you can't change or the indexes aren't suitable for that query. Maybe it's auto parameterizing constants and the query with the problem has a parameter causing different behavior than the original constant used in optimizing the query, or maybe your query with 1000 elements in an in list worked great in memsql or whatever but is slow unexpectedly in the database you ported your app to. There are downsides to everything.