I agree with disabling arm-awapping for -O0.

I agree that we should fix the inconsistency between documentation and implementation regarding the default optimization level.

I agree that arm-swapping E1 -a E2, or arm-awapping E1 -o E2 for any case where the order of evaluation is user-visible is a bug.   Specifically, the only way the user should be able to determine that the execution order has been modified is by using the -D option to ask find what the executed version of the expression is.

As a corollary, it should not be necessary for the user to specify POSIXLY_CORRECT in order to inhibit arm-awapping and thus get correct behaviour.   The user should also, for what it's worth, get correct behaviour for -On for any integer value of n.

Since we currently have a bug, I am OK with any of the obvious approaches to fixing this in the short term (e.g. defaulting to a lower -O value, entirely disabling arm-awapping for now, etc.)

Properly detecting interactions between EXPR1 and EXPR2 seems to be the desirable way to go in the longer term, but for now if we can't do that we may need to disable some features in order to restore correct behaviour.   Perhaps that could be a short-term solution.

While I don't object to adding a configure option to set the default optimisation level, I also don't think it's fair to "export" responsibility for mitigating this problem to packagers.

On the Cost-Based Optimizer more generally, I don't think there have been any systematic measurements of its effectiveness.   It is not impossible that performance benefits arising from it may turn out to be either too small to measure or too small to justify the ongoing maintenance burden that the code imposes.   I wrote the code but I'm not sentimental about it.  If the benefit obtained by keeping it is less then the cost of doing so, we should probably remove it.

Lastly on the spelling aspect, the origin of the problem arises in differences between UK English (of which I am a speaker) and US English.  US English standardised on -ize endings for a lot of words where correct UK English is -ise.   However, the word "atomize" is not one of those words.  In UK English "atomize" is correct.   But because many people are aware of the -ize/-ise differences, there is a popular assumption among UK English speakers that the -ise form should be used there there is an -ize ending in US English.   That's not always the case, but it has led to "atomise" becoming an accepted UK English alternative form of the correct UK English word "atomize".    The same is true of the word "optimize".  I'm to blame for the introduction of "optimise" into the findutils documentation.  Sorry.  All uses of "optimise" should be changed to "optimize".

I noticed something similar before too with -xtype, which was agreed to be a bug: https://savannah.gnu.org/bugs/?51926#comment5