Actually I think of this change more as a bug fix than as an optimization
If you have a system that always generates queries the same way (and there are quite a few of those who use lucene/solr), then the extra work is unwanted overhead. And in some cases, the overhead could be significant (very very large queries... i've seen examples).
One could also check for more complex transformations to make apparently unequal boolean queries equal, and that would be great, but the cost should not be imposed on those who don't need/want it.
Then think about taking one of those large queries and programmatically adding a single clause... all that work needs to be re-done?
The same as checking for duplicate negative clauses - great if you have a system that could generate them I guess, but one should be able to opt-out.
There are so many users, we need to continue to design for the corner cases as well as the mainstream, as long as those needs don't conflict. All that means in this case is to have a way to opt out of all the checking and say "just create me a weight with these clauses". I guess that could just be an expert static method on BooleanQuery?
/** @lucene.expert */
public static Weight createWeightFrom(List<BooleanClause> clauses)