Superficially. It does feel very much like Next.js, but I feel that direction sort of misses the mark, especially coming from a try-to-be-as-transparent-as-possible angle. There's still no opinionated way of doing data fetching (meaning one is free to shoot themselves in the foot trying to chase trends) and for doing non-trivial server-side things, you're basically dealing w/ raw req/res, which tends to devolve into an unstructured mess if the framework doesn't provide guidance (which neither Next nor Sapper do IMO).
For me personally, it has one other showstopper (its file naming convention is not compatible w/ Bazel)
"Needing" is relative. I could make an app making nothing but raw XMLHttpRequest calls, but that only speaks to the capability of talking to a server. In that sense, sure `fetch` is "enough". But from a perspective of a complex application or a complex org, you may want specific properties to be true: for example, you may want that a request to a certain endpoint follows a predetermined schema, or that one can control the granularity of the response data, or maybe you want to abstract over things like streaming, retries or caching to name a few things.
Something that most frameworks struggle with, IMHO, is that they don't consider how coupled network is to the system and when you need to do something like bundle-specific translations in an SSR context, it's very hard to do it in a generic way without touching half a dozen unrelated parts of an app (meaning librarizing concerns that cross-cut across network boundaries is difficult).
