I think you won't be surprised that a) I don't disagree with any of what you wrote, b) I don't think it's super on topic, and c) I think claim b isn't obvious.
For the sake of argument, let's say "a deterministic, permanent virtual machine definition" is a desirable quality. LLVM IR at the latest version is a poor tool for this, yes. But LLVM IR at some fixed version of LLVM works fine. It's weird because now you can't use up-to-date versions of LLVM with it, but it's doable: pNaCl did exactly this, and dealt with forking the LLVM codebase in order to freeze the IR definition. If you don't like that, Java bytecode at some fixed version of the JVM probably works, .NET CIL probably works, WASM works (although it didn't exist when Nock was designed), etc. In fact, Urbit's web page compares itself to the JVM and WASM. Perhaps you could use Infocom's Z-machine, or BPF, or something. Alternatively, maybe you just want i386 assembly or ARM2 assembly or MIPS II or whatever. With a validator to make sure you're not using undefined/newer operations, and with some restrictions on threading and input (including input randomness), they're deterministic and permanent, and you've got a wide array of software tools for generating it.
But I think "why would anyone want a deterministic, permanent virtual machine definition" needs to be answered, if we're going to have any idea of what the topic of this comment chain is. We're talking about whether Nock and Hoon are intentionally obscure, which means talking about whether there exist less-obscure things that solve the same problem.
Moldbug's claim - which, even if he doesn't say it in as many words, seems obvious from the history of this conversation and how participants have read his work - is that a) there exists a set of constraints that describe a thing worth wanting for a real-world application, and one of those constraints is that it be a deterministic, permanent virtual machine, and b) his invention, Nock, is a novel solution that satisfies those constraints. If you don't have that, then Nock is, as 'xkapastel puts it, "somewhere in between an art project and a pyramid scheme."
So, for your use case, I might ask you whether the JVM or i386 assembly or whatever answers it, but for the use case of Urbit, we need to figure out what exactly those constraints are. And then we can evaluate whether Nock and Hoon are novel because they solve problems that haven't been solved, or whether indeed there exists a less-obscurantist solution that satisfies the constraints, and thus Nock and Hoon are simply exercises in "look how smart I am" / "you'd never have gotten this from mainstream software engineering, aren't you glad you listened to me" / whatever.
In other words, I think we are off-topic by discussing the merits of Nock in the abstract, and then constructing scenarios in which we find Nock valuable. (And, to the extent that Nock and Urbit as a whole are potentially exercises in crypto-fascist-advocacy, this would be playing into Moldbug's plan - Moldbug's philosophical work takes much the same approach, of making an interesting-sounding claim and then trying to convince you it has real-world relevance because it's just so interesting-sounding and just so different from mainstream opinions that it must have value, and it too can be defeated by keeping "Okay, what problem are you trying to solve" front and center, and therefore Moldbug wants you to forget about that. If we say "Nock is cool, but I wish it weren't named after an anti-Semite," we make people wonder about the anti-Semite; if we say "Nock is, actually, an unnecessarily-complicated rehash of things that already existed, named after an anti-Semite and dressed up to sound cool," then people understand what's going on.) We should first figure out what the problem Urbit needs Nock for, and then we can have a fair discussion about whether Nock is a meaningful invention.
Incidentally, https://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhn... is an argument that Urbit, as a project, doesn't need a deterministic, permanent virtual machine definition at all - that there isn't a need for future-proof reproducible behavior in the system, that the constraint on using the Nock VM makes Urbit perform poorly, that the escape hatches to help Urbit's performance undermine the whole project (apparently the Urbit runtime statically recognizes a particular Markdown implementation in Nock and replaces it with a call to a different Markdown implementation in C), that the "simplicity" of Nock makes it harder to understand the high-level purpose of programs and defeats Urbit's claim that programs are understandable, that the Nock VM prevents an Urbit user from doing effective runtime resource control which would be a useful feature in practice, etc.