True, but, to me, that sounds like the comments by people who are trying to dismiss the accomplishments of formally-proven microkernels by implying that formal proofs are worthless as long as the code is running on hardware capable of real-world flaws.
I'm a life-long GCed-language user who only considers Rust a viable option so long as my productivity is preserved and I don't have to stress out over my "the only thing I know is how little I know" relationship with C and C++.
If you were to successfully convince me to not use rust-cpython, it wouldn't prompt me to write my own FFI code, it'd either prompt me to port everything back to pure Python or drive me to the next option which provides a similarly high-level API and ability to let me shirk responsibility for memory safety... which would probably be the Python frontend launching a Rust subprocess and controlling it via either D-Bus or JSON-RPC.
Even if I trusted myself to write unsafe code, which I don't except for the most trivial of things, I've only written one unsafe block across all my projects, consisting of unsafe { access(cstr.as_ptr(), mode) == 0 } as a replacement for Python's os.access.
I spent over an hour auditing it, and it still makes me feel nervous whenever I look at it because I know that I saw a post on /r/rust about how there are ways you can write the preceding CString::new(abs_path.as_os_str().as_bytes()) conversion which will compile without maximum-warn Clippy complaining, but present a use-after-free bug.