You touched on the idea in your last paragraph. Comparing Zig to C using memory safety as a binary threshold instead of a continuous scale is apples to oranges.
For one, Rust isn't even at the far right of the memory safety scale, so any argument against Zig due to some epsilon of safety has to reckon with the epsilon Rust is missing as well. That scale exists, and in choosing a language we're choosing (among other things) where on that scale we want to be. Maybe Rust is "good enough", and maybe not.
For two, there's a lot more to software design than memory safety _even when your goals revolve around the safety and stability of the end product_.
So long as you get the basics right (like how Zig uses slices by default and has defer/errdefer statements), you won't have an RCE from a memory safety bug, or at least not one that you wouldn't likely see in Rust anyway (e.g., suppose you're writing a new data structure in both languages; suppose that it involves back-references or something else where the common pattern in Rust would involve creating backing memory and passing indices around, combined with an unsafe block on the actual cell access to satisfy the borrow checker; the fact that you had to do something in an unsafe block opens you up to safety issues like index wraparound causing OOB reads).
If memory safety is "good enough" from an RCE perspective, what are we buying with the rest of Rust's memory safety? Why is it so important? For everything else, you're just preventing normal application bugs -- leaking user data, incorrect computations, random crashes, etc. The importance of normal application bugs varies from project to project, but in the context of systems programming of any kind I'll argue that these are absolutely as critical as RCEs and the other "big" things you're trying to prevent via memory safety. The whole reason you try to prevent an RCE is to ensure that you have access to your files/data/tools and that an attacker doesn't, but if logic bugs corrupt data, crash your tools, and leak PII then you're still fucked. Memory safety didn't save you.
That shift in perspective is important. If our goal is preventing ordinary application bugs on top of memory-safety bugs it becomes blatantly obvious that you'd be willing to trade a little safety for some bug prevention.
Does Zig actually help reduce bugs though? IME, yes. The big thing it has going for it is that it's a small, cohesive language that gives you the power you need to do the things you're trying to do. Being small makes it possible to create features that compose well and are correct by default, and having the power to do what you're trying to do means you don't have to create convoluted (expensive, bug-prone) workarounds. Some examples:
1. `let` rebindings in Rust are a great feature, and I like them a lot. Better than 90% of the time I use them correctly. The other 10% I'm instead trying to create a new variable and accidentally shadowing an existing one. That's often not the end of the world, but if there exists any code after my `let` rebinding expecting the old value then it's totally incorrect (assuming compatible types so that you don't have a compilation failure). Zig yells loudly about the error.
2. The error-handling system in Zig is easy to get right because of largely compatible return types. By contrast, I see an awful lot of `unwrap` in Rust code in places that really shouldn't have it, and in codebases that try to use `?` or other more-likely-to-be-correct strategies the largely incompatible return types force most people into slapping `anyhow` around everything and calling it a day.
3. Going back to error-handling, Rust allows intentional discards of return values, but if you start by discarding the return value of a non-error function and the signature is later updated to potentially return errors Rust still lets you discard the value. Zig forces you to do something explicitly acknowledging that there was an error. 100% of the time the compiler has yelled at me for a potential logic bug it was correct to do so.
It really is just a bunch of little things, but those little things add up and make for a pleasant language with shockingly few bugs. Maybe my team is just even more exceptional than I already think or something and I'm over-indexing on the language, but in the last couple years I haven't seen a single memory safety issue, or much in the way of other bugs in the Zig part of the company.