Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go.
Python has many similar properties, but at least there I can understand that Python is a 'pretty' language to write things in. Java has never been something that I have ever wanted to choose, and far, far less so when there's a big hill to climb like this.
I guess I fundamentally disagree with all the statements in the article like "This needs to change". I don't think it does. I would much rather than people wrote CLIs in Go or Rust than Java, 100% of the time the latter has been more painful for me to consume.
Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years.
The why is quite simple, in my opinion. I see java devs reaching for other accepted tools for such things and opening a whole can of worms by introducing a new language that is only "required" by convention. I would love a rich java ecosystem of TUI/CLI libraries to reuse all of my existing business logic and company libraries. The lack of extremely streamlined wrappers is the only barrier. In my work environment, this would be a great addition.
Its not necessarily fair to use past experience with programming languages that have been seeing major updates year over year. Java as a command line environment has been pretty painless for me, particularly Saxon. Just need to alias the command to include a path to the jre binary.
Python has been much more painful :) no shade on go, of course having a binary built for your system is the most painless.