I think this may be primarily opinion based.
The way I see it, keeping things simple is sometimes the smarter way to design.
To have the compiler accept some code that the compiler currently doesn’t accept, that would (at a minimum) require more complexity. The compiler would have the additional burden of determining which constructs could be allowed, and which constructs wouldn’t. The compiler is plenty complex enough. Why add more unnecessary complexity. Especially if the additional complexity doesn’t solve, or help us solve, a particular problem.
A requirement that the constructor in the superclass runs before any code in the constructor of the subclass keeps things simpler.
Declaring a static method, as shown in an OP example, doesn’t violate the rule about running the constructor in the superclass. A static method is never instantiated. It’s part of the class definition, it’s not part of an instance of a class.
I think making the compiler smarter (to handle Java code proposed by OP) would not be a smart decision at all.
Q: What real problem does the proposed change to the compiler solve?
Q: And what problems would it potentially create?
Sometimes the choice to avoid additional complexity (and potentially creating more problems) is the smarter choice.
2
solved Java compiler stupidity – Constructors [duplicate]