Yes. This is also true for a few other expressions. IIRC, the gimplifier expands MAX_EXPR into control flow, even though it is legal gimple.
In fact it did this, but later it was removed from the gimplifier because it generated worse code.
The usual reason for this type of thing is that the ability to have them as the RHS of a MODIFY_EXPR was added much later than the gimplifier, and it was decided that in order to avoid possible performance regressions, the existing behavior of lowering wouldn't be changed. If, of course, there is some good reason to always use the data dependent form over the control dependent form, we're always willing to explore changing the gimplifier to not do the lowering.
MIN_EXPR/MAX_EXPR in fact are a very good example, because we discovered that it would be best not to do the lowering. In fact, there was no reason why the optimizers would mishandle MIN_EXPR and MAX_EXPR (they are just like any other tcc_binary node). If we had a tree combiner, it would probably be better to allow COND_EXPR throughout the whole compilation, and possibly to generate them from simple phi's like we do in the tree-ssa-phiopt pass. This would leverage some code in fold.
Paolo
