I agree that GraphQL is not the only way to solve them, but it does provide consistent approach to address most of those. At a startup, it's very, very beneficial to be able to point to externally maintained documentation and best practices. It's one less thing to do internally and can help to onboarding new employees more quickly.
I'd rather take on technical debt related to our product features than to load us up on fundamental networking and caching issues.
That's fair. Reasonable people can disagree about these things.
EDIT: Sorry, a bit of a rambly post, too tired and emotional to rephrase.
I will say, though, that "fundamental networking and caching issues" sounds very... weasel-wordy, if you see what I mean? It's not very concrete about what the actual problems you might experience would be. (Yes, latency and huge numbers of requests are issues, but is it really an issue until you get big enough?)
Almost all successful applications in existence until about 2018 (or so? Not sure exactly when GraphQL was invented) has done just about fine. If we're talking about a brand new type of application which couldn't have been done without it, then fine. If not... well, we're not talking about technical limitations.
I truly do see the appeal of GraphQL for developers, and especially the fast decoupled iteration that it enables, at least theoretically. The thing is that when you need more data on the client, you still have to add that data on the server... somewhere. It's great that the client can choose the overall "shape" of the data, but that doesn't solve the problem of the data not actually being on the server.
I'd rather take on technical debt related to our product features than to load us up on fundamental networking and caching issues.