While the preloaded character of some TIM registers may result in surprising behaviour, on the other hand, not using preload where it should be used, may result in surprises, too.

In particular, if ARR is not preloaded and is modified (decreased) so that its new value is below CNT (in upcounting mode), CNT will count all the way up to 0xFFFF or 0xFFFF'FFFF, depending on the width of given timer, resulting in a surprisingly long period.

Similarly, if CCRx is not preloaded and is changed while the counter is running, it may happen that the output compare result changes at the moment of the new CCRx value write, resulting in change of output level at an unexpected moment, yielding a nonstandard length of that one particular pulse.

While this effect is easy to understand, it must have confused some of the users so, that ST put this remark to the description of CCMRx.OCxPE bit (which enables the respective CCRx preload):

The PWM mode can be used without validating the preload register [sic!] only in one-pulse mode (OPM bit set in TIMx_CR1 register). Else the behavior is not guaranteed.

(ST by "validating the preload register" probably meant "using" or "enabling" the preload register. ST manuals are written by non-native speakers of English.) But this of course is nonsense. Writing to non-preloaded CCRx amidst a one-pulse period results in the same confusing behaviour as writing it in normal non-one-pulse mode; i.e. one-pulse mode is no guarantee for different behaviour. And, vice versa, if in non-one-pulse mode, user knowingly writes non-preloaded CCRx with a value which he is sure that at the given moment/value of CNT does not change the outcome of the compare; or if user simply does not care that there will be one non-standard pulse - that write has no other adverse consequences.