If you can deliver responses 10x faster than required, you can scale with 10x fewer resources (or at least presumably some factor of fewer resources) and still stay within the user requirements.

I'd say that's a nice advantage.

These most recent optimizations are nowhere near 10x faster. The only one that can even come close is autovectorization and that can be done without heavy reliance on UB.

If your loop is worth autovectorizing the 2 instructions to check for pointer aliasing, and other showstoppers is not material.

Not everyone is going to be the next Google, Facebook, Crytech, EA, ...

There are better ways to waste money than spending it on YAGNI features.

Consider Parkinson's law... Compare git to mercurial... Consider how many successful Java command line programs are there?

There are plenty of them at the enterprise level.

Just a couple of months ago I re-wrote several Korn shell scripts doing ETL related tasks into a couple of saner Java CLI programs at customer request.

And the responsiveness is good? Isn't there always this terrible startup lag? Could we rewrite the C implementation of e.g. git in Java to get a program that is just as fast (e.g., instantaneous response for most operations)?

Surely, you know that there are native code compilers for Java, right?

Is this practical? What are the limitations? Is this Java spirit? Why doesn't everybody use it? What does this do about startup time?

My initial point in the meantime was only that performance does matter. And that for some reason I cannot recall any (open source or free software) CLI programs written in Java from the top of my head. While there are free Java implementations easily available no?

Many don't use them, because they are commercial tools, and many developers nowadays don't like to pay for software.

The only limitation is that for reflection code one needs to white list which classes end up on the binary.

All major third party commercial JVMs always had the capability of AOT to native code, it was just tabu at Sun.

Oracle has other point of view thus kept the Maxime project alive, rebranded it into Graal, and now those that don't like to pay for developer tools can also enjoy AOT compilation to native code via SubstrateVM, GraalVM and Graal integration into OpenJDK.

Just Windows support is not yet fully done for the time being.

Their long term roadmap is to rewrite the C++ parts of OpenJDK in Java itself, also known as Project Metropolis.

OpenJDK 11 also adopted a feature already common in another commercial JVMs, which allows a JVM to dump a JIT image before existing. Which then allows for AOT like startup on the 2nd execution onwards.

Also Java isn't the only safe alternative to C, those that don't mind lack of generics can just pick Go instead of dealing with C.

Which then we already have several high profile projects using it, including Google's exploratory microkernel based OS.

Correct, it depends on the use case. Nobody is saying you should write everything in C++. But there is plenty of software that actually uses your CPU for data processing where speed is absolutely crucial. If you know that every second (or 100 ms) saved in every functionality your software offers will eventually matter, would you still choose the more pessimistic performance guarantee?

Did you know (at the point where the entire architecture was chosen) that you will get 100 ms with a safer language? What if you got 1000 ms and C++ got 100 ms?

Thing is, C and C++ aren't the only language with those capabilities, e.g. CPU for data processing.

What to live on the danger zone and disable bounds checking on e.g. Turbo Pascal?

Surround the critical performance code path with {$R-} and {$R+}, while enjoying safe bounds checking everywhere else.