things will be compiled before committing anyway
Can you guarantee this? I don't know of any way to guarantee this. But, we can check for it by verifying the POM structure, like we are currently doing. If somebody commits a poorly structured POM, I want the CI server to fail... not to just fix the user's failure to do their due diligence to test before committing. This is no different than adding a checkstyle plugin to the build as so many other projects do. I also don't want to build a clean checkout, only to find that what was built did not match what was checked out, because the plugin just resorted the POM without my knowledge.
If things are being edited in the pom for the release, then there's something wrong
Things aren't being edited in the pom for the release. The problem is that this plugin will potentially edit the pom during a release if you make it automatically sort during a build. The release plugin runs through the build, running all the tests. I suppose we could change things so that the verify happens instead of sort during a release build. But that means that the release artifacts cannot be easily reproduced without excessive documentation to explain why a profile should be activated during a release (tagging), but not when reproducing the release (building the tag).
I prefer the explicit practice of: when you change the POM, make sure you change it in a way that conforms to the standards that are enforced. Then, everybody else who never want to touch a POM can go on about their business without the concern of "why did my POM change when I built? what changes were made and why? how do I fix them?". Those questions should be scoped to the user who made the POM change that disrupted the sort/structure. And verify is the only way we can enforce this.
However (in spite of my attempts to explain the potential problems in detail), I also don't feel very strongly about this.