Overall this sounds great to me. I think a practical application of Compatibility aimed at implementors has long been needed.
When CSS is disabled all content should be correctly machine readable.
I understand the intention here, but I think this might be redundant and seems easily misinterpreted. For one, I think it could be misinterpreted to mean that Grade C browser support is limited to only issues with CSS, whereas TLS, HTTP, and HTML are highly relevant there as well in terms of affecting what can and can't read. (As well as e.g. graceful skipping of the JS payload, etc.) As such, this sentence, I think, is not meant to say anything about unsupported browsers being able to consume the HTML, as those unsupported browsers may be unable to even connect to the web server at all, or may encounter HTML format that will break the layout in some way.
I also don't think we test or support manually turning off in an otherwise supported Grade A or C browser (maybe with JS still turned on?). There may be other conventions we follow that allow this to somewhat work currently as happy side-effect, but any issues specific to it I would decline without second thought.
Perhaps underlying your point is that we should strive use of semantic, accessible, and portable HTML. Thus in accordance with the Architecture Principles, for our content to be easy to re-use, archive, and render offline or standalone. Thinking about Kiwix, IPFS, Apple Dictionary Lookup, Internet Archive, HTML dumps, etc. It might also be worth to consider at least two text-based browsers in the Grade C matrix for longevity, along with a new code conventions page for HTML?