Good questions!
If people can advocate for languages that I would never want to touch, why can’t someone advocate for Zig?
They certainly can advocate for Zig! I am not saying they can’t, I am saying only that I wouldn’t, and why. This is to help others make their mind on the topic!
And, to clarify, I am talking about a very specific narrow subclass of advocation here, “pushing the language”. I am certainly happy to advocate for Zig by writing Zig code, by writing about Zig on my blog, and by speaking about Zig when I am invited. What I am avoiding is going to someone else’s space without invitation and starting speaking about Zig, instead of what that place is nominally about. In a pinch, that kind of thing can actually be useful sometimes, but I think Zig is not there yet at the moment.
Separately, I’d maybe caution against the logic of “if other people can do this on the Internet, why I can’t?” — some people say all kinds of crazy things, and the nature of Internet is that it tends to amplify the most controversial opinions. So, again, for myself, I just don’t care what the others say, I try to reason from the first principles about what’s the right thing (so, don’t listen to me either, lol 
).
Even if someone froze at a particular version of Zig for 5 years, they’d probably have a better developer experience than using certain other languages
The way I see it, the two major forces that shape the ever growing body of software are:
- uncertainty about the future
- path dependence on the past
Decisions made today tend to reverberate decades into the future, often in unexpected way. Circa 1995, Unicode was all the rage, and so all of JavaScript, Java, C++, and windows jumped onto the wchar bandwagon, declaring that a “character” is 16 bits. As a result, most prominent APIs of today are basically impossible to use correctly: String.prototype.charAt() - JavaScript | MDN.
So I am very wary of decisions which are simultaneously hard to undo and carry a lot of uncertainty! And picking a pre-1.0 language is one of the central examples here! A doom scenario here would be, for example, that in five years:
- something happens to Zig (hostile takeover of the foundation, something happening to Andrew, Rust fully eating the world, etc)
- Apple releases a new CPU, O-90, which uses a new architecture yet again (RISCV)
- A new LLVM version supports
riscv-apple target tuple
- But there’s no one to upgrade five-year-old Zig to it
And there’s also more mundane issues like Andrew liking to break the build system in every release 
There are contexts where these can be viewed not as unacceptable risks, but rather as smart bets to make, but I expect those context to be rare, specific, and requiring case-by-case reasoning at the moment.
uped ) reply there was about path dependence, the exact thing I have described above. It is the same concern, just not expressed in terms of version numbers.