Your understanding is accurate. We do plan to support pre-rendering on a route-by-route basis, which will perhaps be more inline with what JAMstack tends to mean today. But Redwood is still all about JavaScript (client) and APIs (backend), with markup to follow, as I just mentioned. But more than that, it's about the development and deployment philosophy of JAMstack that we fully embrace.
I took a look at the example:
https://github.com/redwoodjs/example-blog
As I understand "JAM Stack" the point of the M is to have large chunks of your application pre-rendered.
However in this example; the blog pages are client-side rendered based on a graphql query that goes into postgres database.
Am I missing the point of this? It looks like a standard rich-client with API backend architecture.