The article felt kind of disjointed, I think that statement was just meant generally and not meant to suggest it applies here
Rather than memory safety per se, I'd actually value Rust's type safety over Python's. Yes, strictly speaking Python is dynamically typed rather than untyped, but Rust will shift a lot of your mistakes "hard left" (ie report your goof during compilation not during execution) compared to Python because it gets to do these checks up front, and it is also able to catch a lot more of them because it's much stricter about what types are.
In Python we can write "if foo" and it doesn't matter too much what type foo actually has, Python will try to decide if it's "truthy" at runtime. In Rust either foo is a boolean, in which case this is a reasonable thing to do, or it isn't, that's a type mismatch, your program doesn't compile. Not everyone loves this, but I certainly do.
[0] https://www.merriam-webster.com/words-at-play/sealioning-int....
Edit: Just realized you said "even with garbage collection", so you weren't talking about Rust. Never mind.
https://jcp.org/aboutJava/communityprocess/final/jsr133/inde...
(section 17.4 of the full specification)
However in a sense Rust is cheating. Java has to do a lot of work because they can't stop you writing a data race in Java, so they want that to be safe anyway if it happens. (Safe) Rust just won't emit the data race in the first place.
A data race requires (as mentioned below in the thread about Python concurrency) that there's mutation concurrently with access to the same memory. In Java that's a bad idea, but it does happen, usually by mistake. In (Safe) Rust mutation requires that nobody else has a shared (immutable) reference to the object, so the data race can't occur because if we can mutate something by definition nobody else has a reference to it - programs with this mistake won't compile.