The Rust vs Java question translates to the age old C++ vs Java argument, where the counterpoint is that Java can be faster because JVM has no significant disadvantage in code generation but JIT and GC can be faster than AOT and malloc, and then there are many back and forth arguments and nobody changes their mind.
In another sense, ease of use and HLL properties of languages can in practice give performance advantages. Given the same amount of time, the programmer of a more expressive high level language might have more time to iterate and to do algorithm work that end up being much bigger effects than the relatively small differences of compiler code generation.
(The word performance of course also has meanings other than code execution speed...)
except that people routinely rewrite java code in C++ in 2020 and run around the Java code in circles, even when tuning GCs etc etc, à la https://www.scylladb.com/2020/10/06/c-scylla-in-battle-royal... or Minecraft Bedrock edition (C++) vs original Java Minecraft
How many times have there been rewrites from C++ to Java that ended up being faster ?
A couple of times as far as language implementations go (eg JRuby vs CRuby, even before the whole Graal/Truffle thing). However, that's a niche thing, and any JVM implementations have yet to replace the standard runtimes.
As a rule of thumb, I agree that C++ should generally be considered the 'faster' language.
Also the narrower niche of C++ means that it often makes sense to rewrite a small part of a Java app in C++, but it rarely makes sense to write a small part of a C++ app in Java. This domain difference can also explain the relative frequency of public "made it faster with C++" posts, since those small self contained uses make good posts that aren't entangled with the bigger application.
Not if you use the wrong constructs, copy stuff around in the heap, use ref counting everywhere in longer running processes.
I'm not nitpicking here, in Rust you can get really fast, but its on you to make that happen.
For example persistent data-structures (used in Clojure) are really fast and for some operations and cases even close to optimal.
Performance is hard, and I very much agree with your question here. What has been measured and what are the results.
A lot of the performance comes from the different paradigms though, so it's not always an apple to apple comparison. But I also think that's an assumption being made when talking about a Clojure Vs Rust implementation. In the latter, you're most likely implying using mutable collections, fixed size structs, primitive types, and a tighter memory allocation surface. And not surprisingly, those are the same changes you'd make to your Clojure code base to speed it up (most likely).
You're technically correct, but the typical Java program making heavy use of threads has inefficiencies (and incorrectness) that would be avoided with Clojure's higher level async APIs. As it's easier to write idiomatic, performant C than the "faster" ASM.