I've been writing SQL for ~20 years and GraphQL seems like yet another technology to master.
The exact same thing would happen with a subset of SQL. Keywords such as
WHERE would look familiar, but it would be a different technology, with its own quirks.
The difficulty, actually, is to create the actual subset of SQL. The starting point, I suppose, is to have something very basic. Otherwise, you'll open your API to a series of attacks (Jörg W Mittag mentioned DOS, but I suppose there would be other risks as well). But then, different usages would require adding more and more features, and it wouldn't be obvious to know what should be included, and what shouldn't.
Moreover, developers familiar with SQL would also be expecting their favorite features to be included. And every such feature adds complexity. Say I want to
SELECT ... WHERE ... BETWEEN .... Can I do it? If not, that would be disappointing. If yes, a statement as basic as
BETWEEN could keep you busy for a long time, given that you don't know the underlying data source (and don't know how the data is structured). From a different perspective, imagine developing a bridge between the SQL-style API and, say, MongoDB. How much code would it take?
SQL is not just a language, it's also a series of tools that you learnt to use for the past twenty years. Sure you have your favorite profiler, and you know how to read execution plans. But with an API, you don't have any of that. You don't even have the ability to launch your favorite graphical tool to see what views the API provides, which columns are there, which types are being used, what are the constraints, etc.
I suppose you have used products such as Hazelcast, which, for marketing purposes, pretend that they use SQL as the query language. They are great examples of how bad could it be to reuse a language without actually providing all the features of the language and the tools which come with relational databases.
So, essentially, you end up with something which only looks like SQL, but which isn't, and which brings no benefits and no familiarity of an actual SQL database. And therefore you can't leverage your twenty years experience to work with it. On the contrary, you are constantly asking yourself, why this damn API is not behaving like your favorite relational database, and why you can't use your favorite tool or some SQL statement which would make your life so much easier.
If you have to learn the subset of SQL and its quirks, you can as well learn any other language/technology.
At the same time, junior programmers who never wrote a single line of SQL would look surprised at the fact that they need to use something which looks like SQL to use an API. Actually, lots and lots of programmers don't find SQL particularly fashionable, and would rather avoid using anything which is associated with SQL.