Thanks for the entertaining the topic of discussion.
Regarding #2:
> it seems to me like you're arguing in favor of conveniences that CLI-focused static site generators can't easily provide
I'm not sure why not. I'm talking about a specification of the process (transformations) that the site generator applies to the input, and a (slightly more relaxed) description of what steps the human operator needs to perform. This is something that people usually relegate to some out-of-band channel, like the README of a disconnected repo—at least for the latter part; they usually omit the first part entirely.
Highlighting an extremely relevant piece from a blog post from an HNer that I recently came across:
> the first wall I hit [trying to update the website] was that I: Forgot [...] the esoteric Hugo conventions (has documentation, but it's not easy to parse at a glance) [...] not sure how I could have remembered all of the Hugo-isms, especially since I don't update this site very often and don't do static site generator work outside of this.
<https://social-coop-media.ams3.cdn.digitaloceanspaces.com/ca...> (from <https://corytheboyd.com/posts/2020-03-09>)
Take also, as an example, TBL's comments about the first rough proposal for the WWW:
> [This is a...] hand conversion to HTML of the original MacWord (or Word for Mac?) document written in March 1989 [...] Other versions which are available are: The original document file (I think - I can't test it)
Both MacWord and Word for Mac probably seemed "safe" at the time. In a contemporary timeframe, you could have probably also put a copy in the hands of the last dozen or so people in your phone's contacts, and they'd have been able to use it effectively. That you wouldn't expect to be able to do the same with Pandoc is an indicator of the gulf of overcomplexity that I'm referring to.
(Note Cory's takeaway from his blog post: "let's build it up again from scratch, but simpler.")