I really think the best way to describe it is an attempt to replace C.
Go is only like C in that it's simple. But it's clearly not a direct C replacement. It's not a great language for writing an OS or embedded code.
Rust may replace C in many contexts, but Rust is much more like C++. It adds a lot of complexity to the language and the compiler. I think it does it in a much better way than C++ so I think it is more likely to replace C in certain contexts where C++ did not replace C.
But Zig really is a much more direct replacement for C. It's aiming at the same niche, but in a different way. And considering how much C still dominates systems programming, it should be pretty clear that if Zig succeeds in become a good replacement, the answer to your question is: you'd reach for it whenever you'd have reached for C before.
The only question at this time is if Rust will eat so much into that niche that what's left for Zig becomes too small. Though it could go the other way. Zig is simpler and easier, and you can iterate really quickly with it. There's even incremental compilation now. I suspect tests with debug allocators, the integrated fuzzing, static analysis and LLM assisted reviews, can make Zig just as safe as Rust in practice, with far less complexity. So maybe Zig will eat into Rusts niche (whenever Zig is mature, right now it's going the other way as seen with Bun)
Zig feels like Modula-2 or Object Pascal had been redone with a C like syntax, so an improvement over C with features available in other programming languages since 1978, however it still has some of the flaws like use after free, and the solution is the same as C has been using for decades, debug allocators.
Similar thoughts as well. But also want to add Rust being a complex language is now greatly helped by AI as well.
I think there still a long way to go before the final version of Zig. I am increasingly thinking 0.17 and 0.18 won't even be close to RC. But I really like the direction that Zig is solving a lot of problems not with language features but with its tool chains. Something I thought was obvious and should have been what it is in the first place. Instead we go increasingly big and complex language.
I think there are very few places where C makes sense and C++ doesn't. Its mostly legacy things like the Linux Kernel, or more aesthetic projects like demoscene or suckless. Where its easier to agree to write C instead of trying to agree on what subset of C++ to use (even then its usually C with a mishmash of C++ ergonomics)
That said, leafing through the first chapters of "Expert C Programming" should dissuade anyone of the idea that C is a simple language. It'll leave you amazed anyone's been able to write working programs in it