They were never intended for the same niches. Go is a Java/Python replacement. Rust is more of a C/subset of C++ replacement. They were compared mostly because they had usable versions released at approximately the same time, but you (correctly) don’t see those comparisons anymore.
The definition of "same niche" is doing a lot of heavy lifting.
There's a marked difference between what these tools became and the impression of them along the way and the axes along which they were compared in actuality. In the simple "I need to build a backend" conversation, Rust and Go were comparable long after Rust changed to a "real" systems language -- I'd go as far as to say people still compare them to this day (and Go probably wins that larger niche for many contextual reasons).
I think the point is partially reflected in your own statement -- there are many axes along which Go is not a Java replacement, and is not a Python replacement either. The definition of the "niche" vastly changes the answer.
For example, if you pick the right niche (e.g. HFT) Java meaningfully outperforms Go because high performance Java is... actually high performance -- those millions of man years into the compiler, runtime, etc produced progress. That said both of those languages get trounced by the FPGAs and custom hardware in the end.
I'm not convinced it was always wrong to compare Rust and Go, but the modern understanding of how different they are today is definitely better/I am glad they're more separated/more people know not to directly compare them.
Just because Python is dynamic, doesn't mean it lacks the notion of a type system, or the whole set of concepts that Go has no way to express, like meta-classes, multiple inheritance, comprehensions (eager or lazy),....
Many folks going from Python to Go, would never done it if Python had a modern JIT on CPython, or the package management wasn't the way it is, hardly anything to do with the language itself.
Same applies to all other remaining types.
That is how even though people see Lisp as a dynamic language using only lists, in reality most Lisps (and Schemes) since the 1980's have all necessary types to write machine friendly code (aka mechanical sympathy), including having existed graphical workstations that only failed the market because UNIX and C were as cheap as free beer for all pratical purposes.
Static type checking is nice and is certainly my preference, but dynamic type checking doesn’t mean no types. It means the types are checked at runtime.