I disagree it could ever be just an edge case because the use case hasn't disappeared and will likely never disappear. Blog posts come to mind as an obvious example, but also encyclopedias, research... Anything that simply needs to transfer nearly pure information instead of providing interaction.
Of course the app use case has grown tremendously and is probably the more important one for casual users which are growing in number in relative terms, so I understand where the sentiment comes from.
One could say that even in many of those cases the original concept of document does not really apply. Blogs have comment section, wikipedia allows you to modify the document itself, and so on.
Not to say that these are less of a document, just to say that most usecases are still moving toward using the web as an application delivery platform, even if that application purpose is to show documents.
Yet many of these use cases can be delivered to the end user as a document. Consider Hacker News. I am able to browse the site and submit comments in web browsers that do not support JS. (This comment is being submitted by one such web browser.)
This approach does not work for everything, nor does it work for everyone. Someone creating a blog post is probably going to prefer the use of JS to make their browser work more like a word processor. It can be done without JS, but that typically involves some form of markup that only a handful will enjoy. You can offer a map service without making it behave like an app, but most people will find a more interactive user interface more efficient. You certainly aren't going to be able to create emulators of vintage computers without JS.
That being said, we can do an awful lot in a useful way while serving up static documents.
My separation of document/non-document was not about javascript, it was about the type of functionality the site offers.
I would call a site like https://danluu.com/ document focused, while hacker news is focused on being a platform for conversation and a ranked news feed.
If you were to download danluu.com and brouwse it locally you wouldn't miss much, while if you where to do the same for hacker news you would only get one part of the offered experience.
Javascript enables this difference to grow to much greater extents but it is not necessary to me.
I don't consider having the ability to edit a document collaboratively contradictory to the document use case. Sure, the editing plumbing is an app, but the core of it is still a document. Contrast this to something like a game or a web shop, which gravitate much more distinctly towards the app use case. Someone else mentioned how the web was envisioned to be editable from the start.
Thinking about this - at the start, the web was intended to be editable as well browseable. the very first browser, WorldWideWeb, was also a web editor.
Of course the app use case has grown tremendously and is probably the more important one for casual users which are growing in number in relative terms, so I understand where the sentiment comes from.