Extra language specification rules that you need to be aware of for your whole career... in order to make the first 30 seconds easier when looking at hello-world for the first time.
The genius of this proposal is that besides the implicit unnamed class, the other changes are all purely done to the program launcher program, no changes are proposed for the language at all.
And one could argue that quickly writing up some program happens often regardless of skillset (I do make at least two psvm Main classes per month), so the code reduction there is also a welcome change.
Well, there is nothing in the spec that says would forbid the JVM loading a ProgramLauncher.class file with a public static void main method, which will look at the program arguments and if it has something ending in .java, it will compile that file, and load the resulting class (current mode of execution).
Also, even if it might become a spec change (a language level one, not a jvm level one), it will be an additive change, at worst some new program won’t run on older JVMs, but all old program will continue to run on new ones.
I think there is more value to a terse declaration of 'main()' than people think. In C#, you can declare a quite functional microservice under 90 lines of code with asp.net core's minimal api format. To this day I think the "enterprise style religious OOP+SOLID Java/C#" is something that has to go - so many applications that take 30 files and 4 projects could've been declared in 3-5 files with the most of core logic being in Program.cs that you can grasp within few seconds of looking at it.
It's also a reaction to languages like Kotlin that already have these and run on top of the JVM. With Kotlin these don't apply just to main. IIRC, other JVM languages have similar reductions in boiler-plate compared to Java.
And one could argue that quickly writing up some program happens often regardless of skillset (I do make at least two psvm Main classes per month), so the code reduction there is also a welcome change.