Just to clarify…
The only issue is when you restart HA or reload automations (and if you save an automation in the UI editor since that automatically does an automation reload) while an automation is actually running.
So yes, it is technically possible to have issues with the automation that contains a 10 second (or even a 1 second) delay if you happen to do the above two things while the automation is actually running (waiting for the 10 second delay). And this doesn’t just work like that for delays either - wait_for_trigger, wait_template and even timers suffer from the same limitations (except timers aren’t affected by automation reloads but the automation that uses them are cancelled so it’s effectively the same result).
But it will only be an issue for that one automation and only for that specific run. Other non-running automations won’t have any problems.
But the point Tom was making is that the odds of you restarting/reloading during a short duration delay and screwing up the automation is less as the delay in the automation is shorter.
My comfort zone for a delay in any automation that I really want to run accurately is 5 minutes. Or even less if it’s absolutely critical. Anything longer than that I shy away from delays directly coded into the automation unless I really don’t care that much if the automation doesn’t complete on time. Then again I do a lot of tweaking so I am more likely to restart/reload way more often than someone who just “sets it and forgets it”. For those people long delays are perfectly acceptable and won’t cause any issues at all.
State triggers are the best way to mitigate those limitations of timers/delays but if it isn’t possible then the only way to get truly reliable delays is to use an input_datetime to set the actual time that you want the action to run.
So in summary, a 5 sec delay should be just fine the vast majority of time.