Despite all of these things ringing true for me as well at the last few companies/projects I worked at that used graphql, I will say that like everything in tech, there are trade offs, but if the tool generally solves the problem you have well, you'll be motivated to find solutions to the additional problems you have - which often means the argument actually comes down to who is more passionate about the particular tech.

One example that stood out to me though:

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

GraphQL the standard doesn't provide tools no, but I've been very successful using Apollo Studio to solve this as (in my experience) the workflow maps to how you generally develop applications:

1) agree on some schema 2) make a (Apollo studio) "branch" with the schema change 3) mobile & backend devs (typically) code gen the objects they need for the schema 4) backend dev deploys a preview branch of their implementation, mobile dev points the client to it 5) test it, merge it, publish the schema on the main "branch" - deal with the breaking changes if Apollo warns you of them.

So maybe you can accomplish this with other tools, and maybe it's not fair to compare "the standard" to a particular tool, but I usually say I stick to gql (where appropriate) because there is a tool for it that works so well for the problem(s) I'm typically solving.