Likewise on the C++ side, someone has to write those constructor/destructor pairs, and there are ways to get RAII wrong.
Yes, you have to think about ownership. Because of single owner. But in general, not alloc/free. I work in Rust (after doing C++ for the 10ish years prior) full time and a couple nights ago was honestly the first time I had to really think about this (I had to do a 'forget' because I was passing a ptr to a vector back through from WebAssembly to our Rust-based runtime, and then clean it up back there instead of having Rust let it fall out of scope and free when the stack frame exited).
Think of Rust as a world where pretty much everything is inside a std::unique_ptr.
Most developers used to a GC language will have little problem working in Rust once they understand the single ownership model.
Async can be a pain, but you learn the ways. I work in a codebase with quite a bit of it.
There are appropriate and inappropriate places to apply Rust.
Yes, the compiler is - for almost all structs. I've been working with Rust since around 1.0 and I can count the number of times I manually had to write Drop implementations with my hands. Unless you are writing lower-level parts of the stack (which you rarely need to, since for many of those there are good crates already available) where you are responsible for resources that need a custom Drop implementation, the auto Drop implementation is good enough.
And for Rust standard library, where the Drop actually does something, someone else wrote the implementation for you.
Once Loom&Co get merged, the JVM is going to be unrecognizable. It's also very possible that one of those Kotlin-native/GraalVM AOT projects goes mainstream. But right now it's a problem for high-performance systems.
Personally I regret this trend because Java/Golang are much easier for people like me than C++/Rust. I cannot imagine myself going back to manually managing memory. Browsing Big Data open source code will not be as educational anymore.