Overflows are registered in timer0_overflow_count, making it possible to calculate further how long the arduino has really been running beyond the unsigned long limit ...
This is not correct. That variable counts the number of times Timer0 overflows (which itself happens every 1.024 mS). It is used in one place only and that is to return the correct value from micros(). It is not a "millis() overflow count" as you seem to think.
I personally prefer resetting timer0_millis back to 0 manually in a periodically fashion to prevent any weird stuff from happening every 50 days.
This is not a useful thing to do, any more than resetting your kitchen clock each evening to stop it "rolling over" at midnight. For one thing, it isn't necessary. For another, while you are resetting the clock it is no longer counting the time.
If you have any reasonably complex sketch where you need to count multiple intervals then there will be no obvious time in which to reset the timer.
It is better coding practice to read timer0_overflow_count before and after long-running operations ...
No, that achieves nothing, as I said above.
The others are quite right. Something like this always works
if (millis () - startTime >= interval)(Given that startTime is unsigned long).
// do something
Example is given in OP. When dealing with large intervals, uncertainty of roll-over increases, making the possibility of negative return on comparisons (smaller number minus larger number) greater.
How can a negative return be possible on comparing unsigned
numbers? That is the crux. It isn't possible, and thus you get the correct answer. What other answer could you get?