Following the PLA (Principle of Least Astonishment), since it is "unusual" for a class to have a main() method (not many classes define them), it makes sense to put it at the top of the class.
All arguments about code style and code formatting should be made primarily from the standpoint of readability. Many developers will argue that methods ought to be designed in order of dependence–in other words, a method that calls another method should always be defined after the one it calls–as well as a million other things.
To understand if these are good conventions or not, I always ask myself: does it make the code more readable? If I encounter a bunch of packages containing code I've never seen before, what are the styles and conventions that will help me figure things out the quickest?
I find that the biggest help for well-designed classes is to list things in the following order:
- main method
- public enums
- public constants
- private constants
- public methods that implement interfaces (from most to least visible, this generally means most general to most specific)
- static methods
- inner classes
- static inner classes
Of course you could argue with specific aspects of this ordering, but it generally follows the principle and at some point it matters more than one is consistent across the entire code base than the particulars.
The main() method, however, I feel is an exception. That one should be placed at the top because it is used so infrequently that it should be front and center for the reader when it does exist so they don't miss its presence. Simply being consistent in putting it at the bottom in the case of a main() method doesn't make sense because wherever it appears has the capacity to "consistently" surprise the reader.