I was a witness to a decision on whether to migrate an old Java project to Go. A proof of concept (a Go rewrite of a core part of the engine) convincingly showed that the Go version would be somewhat more performant, would have vastly better startup time, and would have a smaller and simpler codebase, since the Java version's caches and latency-hiding complexity would not be needed.
The decision made was to stick with Java.
Why? Because rewriting the long feature tail of the Java version in Go and ensuring bug-for-bug compatibility with the Java version would have taken multiple engineer-years. During the rewrite, from the perspective of the project's users, development would have stalled. It made more business sense to instead use those engineer-years to implement some new features that users were demanding. And after all, while the Java version's performance wasn't amazing, it was acceptable.
The decision made was to stick with Java.
Why? Because rewriting the long feature tail of the Java version in Go and ensuring bug-for-bug compatibility with the Java version would have taken multiple engineer-years. During the rewrite, from the perspective of the project's users, development would have stalled. It made more business sense to instead use those engineer-years to implement some new features that users were demanding. And after all, while the Java version's performance wasn't amazing, it was acceptable.