All three cases are actually covered (full-script support, partial-script support, and noscript support). That's more resilient than most apps.
It is sad when the brightest minds in the world decide that the fix for "flash of unstyled content" is to show no content at all for close to 10 seconds.
Seriously: 8 seconds mandatory waiting would have been considered slow even 10 years ago and the only reason it passes now is because Google got a stranglehold on most of the web.
Edit: improve last paragraph
(Disclosure: I work at Google on making ads be AMP)
Perhaps a better option is finding ways to prevent content jumping around so much while assets are loading.
That 8s timeout is for loading the AMP JS from the CDN. You want a time limit that separates "you're on a slow connection, keep waiting" and "just give up, it's not worth it". I suspect it was set by looking at network graphs, but I don't know.
What the OP is doing, blocking JS and also ignoring <noscript>, is bizarre, and something you should expect to break sites.
> Perhaps a better option is finding ways to prevent content jumping around so much while assets are loading.
AMP does that very well, but only by taking control of the process of rendering, which requires JS.
(Disclosure: I work on making ads be AMP.)
This principle is also true when writing web pages; if you load an external resource, you need to check for and handle the case where that resource might not be available. Failing to load a resource can happen for many different reasons, not just someone blocking it with their client. Proper handling the error depends on what the resource is: display the content that is already available (perhaps in a less than ideal state), or if that isn't possible displaying an appropriate error message. This includes cases where the Javascript itself isn't available (for any reason).
Networks are not reliable or universally available. Quality programming understand that and does the best it can when failures happen.