> now standard "infrastructure as code" [...] check in a spec for a container (Dockerfile) into VCS
This is an example of the "predilection for certain systems and ways of working" that I referred to.
> it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?)
That's not really what I meant. My reference to WordPress was probably more misleading than I intended.
I really mean it when I say a human-readable document that's more SOP than blog post—it's not a metaphor. Consider a static site generator for an existing site, and consider the steps it performs on the input to produce the output. Specify these steps as a single, written document—one that you can print out, even. If you're doing it right (in contrast to how we "have been doing it all wrong" up till now), then you should be able to ask yourself, "Is this document suitable for publishing a copy of it on my site itself (or printing it out and dropping at the bottom of a filing cabinet)?", and you should be able to answer "yes".
(This is where the reference to WordPress came from—it's not exactly a "single document", but it is a bunch of PHP files that you could conceivably stitch together and consider to be one and which you can take a peek at so long as you're self-hosting. But even then it's not something generally available as another piece of content on your site, because WordPress doesn't "reveal itself" as such, i.e. there's no associated HTTP resource by default that's associated with the underlying WordPress-in-PHP engine itself, so its likeness as an example is strained.)
That still doesn't solve hosting and portability, but it's a separate matter from the authoring tools (etc) experiencing rot. In practice, this can be covered by the inclusion of an annex to the above SOP (or a completely separate set of procedures) that describes how to get your generated files onto whatever host you're currently using. (In software terms, this section would describe an "adapter" and its use.) Static site pages are already pretty portable by their nature, and you don't really move around enough to worry about it, really, but if you do move, then just document the new process by speccing out a new adapter.
The takeaway is that if these processes are too elaborate to be documented in this way, then it won't work. But if that's the case, then they're already too complex, period—which rules out Docker and pretty much anything else that's "standard" in the devops world right now. I've prototyped something like this, and describing the whole thing that fits into a document weighing <500kB without even trying is pretty easy. My prototype is actually currently at 109kB, but that just covers the build SOP. Albeit, that is both man- and machine-readable (i.e. machine-executable), so it's detailed to a high degree of rigor. That's one long document that includes stuff like formally describing how the SHA-1 algorithm works, how Markdown gets processed, how templates and includes work, and so on. The adapter doesn't really exist, though; since it's a static site, it's just a note that says, essentially, "use rsync; here's the hostname and the exact command-line flags". In the document specifying how building the content from source works, I punt on specifying YAML, because a drastically simpler subset (i.e. colon-separated, key-value fields on separate lines) was able to accommodate 100% of how my frontmatter already looked.
I don't think relying on underspecced and inscrutable commercial systems like GitHub Actions is especially simple, resilient, or healthy. It seems to be subject to exactly the sort of rot mentioned before. Basically, what you said about VCs' blogs.