The things you list that couldn't be implemented in such an environment are a mix of two things, first, things that browsers are specifically designed to _prevent_ a web page from doing, e.g. to avoid leaking privacy, and second, things that absolutely should be possible in that environment, because if they're not, then the environment isn't yet complete.
But in practice I don't think either is especially critical. You can already do pretty much what I suggested just by running the Wasm code against WebGL in a stub HTML page; it hasn't stopped people from creating such things (e.g. Google Docs, Figma, Flutter, etc). The core thing I proposed was allowing the inversion of the architecture so that the Wasm code could be a top-level resource the same way text/html and application/pdf are today. Sure, it could be improved in time by allowing some of the things you list, but that doesn't mean it wouldn't be useful today. The perfect is the enemy of the good, and all that.
FWIW, while I represented Google in the HTML working group (for a few years; it was a complicated relationship), my work on HTML at Google was primarily done via the WHATWG.
I was not involved with AMP's development at any point that I recall.