Replacing circular structures with IDs is memory-safe, but it can still blow up if there is no item with that ID. It may be safer, but it's not guaranteed correct or anything like that. In these cases I'm not sure what is gained by Rust over C++.
That depends entirely on the implementation and use case. An append only arena, like is used in compilers, do not have ever invalid IDs by construction: you get the ID back after inserting into the arena and have no way of removing the value after that. For a use case where arbitrary removal and editing of existing values is needed, generational arenas are used so the handle encodes the "generation" of the value. If on access the generation doesn't match, it means the same as a null pointer and you won't get a value back, in a language with sum types represented with a None sentinel.
Disregarding entirely the memory safety aspects of turning a pointer access to an index access, there are benefits for using arenas (or struct of arrays) like better cache locality on access/avoiding memory fragmentation, and bunching values that don't outlast each other into a single free operation.
I'm actually surprised their example wasn't the accidental use of a valid ID, not an invalid one. An invalid one is easily catchable, but an invalid one is akin to a bad pointer. The resulting behavior will slip by the Rust compiler, as we're basically using integers as pointers, and you can get all sorts of shadow-clone versions of malignant pointer behavior like use-after-free in such a scheme.
That said … there are ways in Rust to do circular data structures that don't have the problems that using indexing into an array has, and are memory safe, and are within the safe subset of Rust. (E.g., Rc/Arc.)
Whether software blows up or not if an ID is "bad" depends on how it's written. Writing a token to a database without cleaning it up could lead to a security hole that has nothing to do with memory exploitation. I worry the fixation on memory is creating tunnel vision.
Herb Sutter makes that point though somewhat hidden amongst all the apologetics... let's not forget there are security vulnerabilities that don't originate in memory access violations. "Easy" config mistakes, bad secrets protection, and human-factor-exposure are out there and don't depend on memory safety. Being humble about that would be only fair.
"Blowing up" immediately instead of corrupting random memory locations is pretty much what's desired though. Everything else is just icing on the cake.
