The default value of the flags reflect the historical behaviour of the functions before the flags were introduced, so that the behaviour of existing code would not change.
Why sum or max had those historical behaviours is a different question.
sum() in the presence of nan inherently mixes information from all the the elements, so if one element has undefined value the sum must be undefined.
max asks what the relationship is between elements but does not mix information. If you have a nan and a definite value then ieee 754 defines the comparison operators: nan compared to anything returns false. It is therefore possible to define a sort order with nan by asking at each point "is this nan greater than the element further on? And since the answer is false you can say "okay, do not move the nan later", so you would not bubble the nan to later. By itself that is not enough to bubble the nan to earlier, but by carefully crafting the question of what it means for two elements to be ordered, you can build a sort. If you ask the question "is this proposed definite numeric value less than this nan?" and since the answer is false you are justified in saying that the definite value is more extreme than the nan.
Therefore it is not inherently mandatory that a nan should poison the max() operation: it depends how you define max(). As compared to sum() in which there is no loophole: ieee 754 defines clearly that anything plus nan is nan. The complications in ieee 754 come from the question of how to handle mixes of Signalling Nan and Non-Signalling NaN, which is an area that MATLAB is not compliant with.
