They want the right to fork, call their fork Rust and compete with the main repo for users. When asked how having multiple competing repos all claiming to be Rust would be beneficial to the Rust community they had nothing to say.
Being able to call the commands of a fork rustc, cargo etc would allow trivial drop-in replacement in case the official toolchain takes a bad turn (for example with analytics).
Furthermore, being able to use Rust in your fork's name (e.g. g-b-Rust) makes discovering better forks a lot easier, as opposed to the names insanity with Firefox derivatives
There's just little benefit for the public in this Mozilla's fixation with trademarks, open source thrived for decades without it (I know that Rust is not in Mozilla anymore, but the legal culture evidently persisted)
To be clear I believe they have good intentions: they think the book is a good enough specification and they don't want Rust to be sabotaged by bad ideas. But it's an unusual and somewhat untested arrangement: the Rust Foundation's general insistence that Rust = rustc + cargo + authorized backends like GCC seems like a significant technical risk that has gone badly underdiscussed. Too much of the community sneers at the idea of formal specification, but there is no magic spell that guarantees good management in perpetuity at any single organization. Obviously specification has its own problems and risks. But I think the issue has drawn a lot of snitty fights and bad-faith blogs - mostly Rust critics, to be fair - and very little serious discussion.
If you're just forking a repo on Github and upstreaming patches, then the likelihood of confusion is minute. Github's users know what a fork means, and if they're the only audience, there's no problem.
If you break the upstreaming link, distribute release packages, market to non-Github-users, and so on, then the likelihood of confusion grows. At some point, a court would probably assess that trademark violation had occurred.