Here's how I think of it. (Others can correct or elaborate my understanding.)

Let's say you have 1 REST endpoint such as "xyz.com/customerlist" to return a JSON response and behind the implementation is a SQL "SELECT ∗ FROM T" and you get back a 100k response with all rows and all columns. You really only wanted customer's name and zipcode and you only wanted it for region of New York. (Unfortunately, "SELECT ∗" returned 30 columns which is 28 more than you need. The REST endpoint also didn't have a SQL WHERE clause which returned all 1000 rows where you only needed 20 rows.) You actually only needed 10k out of that 100k so you threw away 90k of data. Downloading data you throw away is especially wasteful with smartphones on slow mobile connections.

To address the finer grained slices of data, you either create more REST endpoints ("xyz.com/customerlist_name_zipcode") or add query parameters at the end of that 1 REST endpoint. It's doable but multiple endpoints will lead to a combinatorial explosion and the maintenance of them is not ideal for fast iteration.

With GraphQL, the client can request the "shape" of the data without having a pre-defined static REST endpoint that matches that shape. You can thin-slice the data without wasted bytes. The clients can get unforseen shapes of data that the developers of REST endpoints didn't envision.

I actually think the GraphQL landing page explains the rationale and motivation very clearly: http://graphql.org/