With an alternative design you'd need to have some other code container concept, but it'd be almost exactly the same as a class file. If the JVM also had a separate notion of a non-class file, just hold to hold static methods, then it'd boil down to duplicating the format. Most languages decide to make the source file the first-class container concept, or in native languages, the DLL/.so, but this isn't obviously better and comes with its own downsides. Orienting the VM around classes has a bunch of upsides that contribute to Java being successful.
The real complaint here is more about the syntax boilerplate involved in writing top level functions in Java that map to classes with static methods. Kotlin shows there's no deep reason why the Java language has to be written this way, it's just notation. They picked it to avoid complicating the language with special cases, but I can easily agree that smarter syntax is more important than the Java guys have historically believed. Kotlin is proving this at the moment.
The real complaint here is more about the syntax boilerplate involved in writing top level functions in Java that map to classes with static methods. Kotlin shows there's no deep reason why the Java language has to be written this way, it's just notation. They picked it to avoid complicating the language with special cases, but I can easily agree that smarter syntax is more important than the Java guys have historically believed. Kotlin is proving this at the moment.