Here is the thing, for you or anyone who cares.
If you can get to the point of recognizing that fluency in debug tooling combined with certain ways to structure your data and certain programming practices can end you up in place where it becomes debatable whether Rust or 'C and its ecosystem' is a better workflow. Then even if you did believe the Rust approach of front-loading extra steps to pre-emptively avoid all memory bugs by static analysis is better, you still have not arrived at a skill which is portable to all problem domains.
What if you then need to start off-loading portions of your system to the GPU? Or another specialized chip? Or you need to start dealing with a problem that requires multiple processes? Or interfacing with low level hardware I/O? Or you do need to drop down to assembly? Some problem domain which static safety analysis can never make safe? And a substantial meat of your application is dealing with something in this problem domain?
Now you are back at square one. You have to take the time to learn and get comfortable approaching such problems the way you would with plain C.
Not necessarily use C itself. Use whatever you like that can generate the necessary instructions at the hardware level to make it work. Ultimately that doesn't matter.
But the fundamentals of how you deal with such problem domains are the same irrelevant of the exact language and syntax you use. Doing it in C, or Zig, or CRust requires exercise of the same fundamentals. And if to this point thus far you required the static safety analysis of Rust to be effective. This means you have not been learning some kind of universal future approach everything will adapt to. It means you have a barrier in your ability and certain problem domains you will struggle in.
What I personally find is the more exhaustive approach of front-loading extra steps in safe Rust is ultimately not easier than other ways if you are comfortable with the other ways. Much of it starts to be ritual for the sake of formality on things which would not have been an issue or would have been trivial to deal with. Or at worst makes certain approaches impossible for no reason other than formality. Then you combine that with it not being a universal future approach to every problem, but something that will be a barrier that you still will have to develop the comfort and muscle memory in the other ways to get past. That ultimately, it's a detour into a bunch of other "stuff" that's limiting and not necessary.
A lot of people are perfectly happy being a Ruby developer or JavaScript develop or Python developer their whole life. Or a Rust developer. Staying in a curated sandbox of defaults with boundaries which can have certain niceties for particular problem domains. But it is that. A subset.