It would make sense for a highly succesful but stable java project to be replaced like that, but since I'm in the java world, it's usually replaced with another java project.
I could provide examples myself, but I'm not convinced it's about java vs c++ or go: hadoop, cassandra, zookeeper
As an outsider, Java looks like a language that can be very fast but it seems like certain idiomatic practices or patterns lead to over-engineered and thus sometimes also slow projects. The Factory<Factory<x>> joke comes to mind.
Because once you have a base codebase in a particular language, it is silly to rewrite it in another, as ultimately language choice doesn't matter that much. But if you are going to rewrite stuff from scratch, Java is a horrible choice in the modern age.
When talking about Java, the question that anyone should ask is how was log4shell even allowed to happen? Like in what world would giving permission to a logging library to a) fetch code from the internet and b) execute it, by default a good decision? This wasn't a bug, it was an intentional design that passed code reviews.
Java hasn't focused on developing the standard libraries to keep up with the modern world. There is no standard http server or API libraries. A lot of the "standard" libraries in software projects are from 3d party sources like Apache, which obviously can't be trusted if they make decisions like above.
Lombok is still heavily used, and its almost a sin to write getters and setters manually instead of using it, but it works by hacking the AST, and the language maintainers never thought to include that as part of the language features.
Furthermore, the biggest use of java in android app development has shifted to use Kotlin instead, because Kotlin aims to address a lot of the pain points of Java. Yet language maintainers of Java don't seem to care.
So overall, if you look at the java ecosystem, its clear that the people working in it have no connection to use in the real world, and are taking the language into some direction that fits their convoluted ideas of what a language should be.
From a more functional perspective, in the modern age of the cloud, ARM chips, and cheap memory, developer cost outweighs infrastructure cost by orders of magnitude. If you write your service in python for MVP, you end up saving a shitload of time, through things like massive amounts of 3d party libraries, not having to wait for compile step, being able to develop during debugging session, much more flexibility in how you write code, and so on. Then as you move from MVP to a product, its much easier to refactor the code with MyPy type checking, convert collections of functions into Classes if need be, and so on. Finally, with PyPy running your code much faster than than CPython, you still will on the average be slower than Java, but not by much, and the added infra cost will be much less than a single developer salary per month.
More than that. It is a nightmare to make binding for. So if you want to really be extensible through plugins, supporting other languages is very important.
The fact that this is so common I think yearns for a language that is basically python and rust smashed together where a project would have some code in the python side and some code in the rust side intermixed fluidly like how you can drop to asm in C. Don't even really try to make the two halves of the language similar.
An embedded interpreter and JIT in rust basically but jostled around a bit to make it more cohesive and the data interop more fluid— PyO3 but backwards.
It's not really a "decision" thing, more that the pattern of write most of the code in python, rewrite the performance critical bits in rust as a cpython extension would be nice if it were made first class.
