It’s done in an extremely verbose OO style (everything must be treated as an active object, even things that are by their nature dumb data), tries to compensate for that by providing shortcuts for the resulting multiple-level accessor chains, but with no rhyme or reason wrt which shortcuts exist and which don’t. There are also some things that ought by the nature of the problem exist in the implementation, but are not exposed, and the official docs literally have you reimplementing them (IIRC an official way to see which Sheets rows are selected by the currently active Sheets filter was only provided relatively recently, and you still have to redo date formatting yourself). And maybe the verbosity is no big deal for the original consumers of the API, but in the GAS environment my impression is that every method call is an RPC that takes tens of milliseconds. The bottom line for me was that fetching a couple thousand cells from Sheets as a JS array and then just processing them in JS without touching any of the Apps interfaces turned out to be a couple of orders of magnitude faster than trying to figure out exactly which cells I needed and fetching then individually, even if I only really needed a couple dozen in the end.
I guess the real question is: why would anyone do it this way? I recognize that what the API is doing is in fact much more complex than it appears, because it’s a complicated distributed system (then again, when it was a VBA macro running on my desktop it didn’t need to be...), but why does it give the impression that noöne actually cares about the ergonomics? Even its original Javaish ergonomics, let alone given the fact that JavaScript is not Java.