Sure there's diminishing returns from ~1-2 seconds page change for a DB-backed site (slower ones anyways) to the ~500 millisecond page change for a normal static site generator to the ~50 milliseconds for a React-based one but it's still a significant difference.
But in any case, client-side routing to me is a nice-to-have not the killer feature for Gatsby. Building web sites with the React component model is the killer feature for me.
Another point in favor of this model is because routing is client-side, page changes are consistently fast. In best-case network conditions, normal static sites are very fast but throw the user on a glitchy 3g network and you'll soon see 5-10 second page loads. The same site built with Gatsby will still see instant page changes as page data is precached.
That's a big advantage, but at the same time you're pushing content to a user that they might not want, or ever see, which could be a problem for users on poor quality 3G networks. If bandwidth is at a premium a developer shouldn't waste it.
"Bandwidth" isn't the problem on 3g generally. What does cause UX problems is high latency. Speculatively precaching content is basically the only solution.
FWIW, while I'm in the US so don't really understand developing for very poor networks, the methods I'm describing is exactly what companies in India and other places with poor networks are adopting: https://developers.google.com/web/showcase/2016/flipkart
But in any case, client-side routing to me is a nice-to-have not the killer feature for Gatsby. Building web sites with the React component model is the killer feature for me.