I think there could definitely be gains made from having a debugging frontend written in Rust, even if the backend is entirely either C or unsafe Rust. Even if gdb needs to use many low-level constructs to actually do the debugging, it doesn't need those for anything else: reading debug information, coordinating with a command line interface and matching up bits of binary code running with source code could all be done in safe rust.
This could mean making gdb even more robust than it is now, and as existing rust projects have proved, limiting unsafe code to particular program modules is still extremely useful even if you don't eliminate it entirely.
If the gdb team announced that they were considering rewriting portions of the codebase in Rust, I'd be excited.
With that said, I personally wouldn't be excited to work on a new rusty gdb as a hobby. It's a big project, and rewriting it in a reliable way will be hard. I like doing things which have a decent impact-for-the-work-done ratio, and this project really doesn't sound like it would.
What I want most in a debugging tool is reliability. But gdb already has reliability, and performing a rewrite is erasing all of that - it's starting from scratch. And for what, a more maintainable codebase? gdb is already being maintained, and even if we forked it, gdb would still exist, and it'll still be being maintained. Without new features and without the original developers, a rust fork has nothing to offer.