That is not the biggest reason (pun intended) to be cautious about this approach.
As @lacsap pointed out, the more important reasons are variability of the fields on which you test and compete due to anti-static application, field setup tolerances, robots starting to fall apart after collisions, etc… which time based reruns may not handle well.
That is a very simple yet effective way of improving accuracy without starting to make code more complicated. Special handling of the claw motor was also a nice touch.
Simple reliable time based autonomous could work better than the poorly configured PID based code. However, well written code that relies on the feedback from various sensors to do odometry and PID control, will undoubtedly work better in all circumstances.
The best part of @Sylvie’s tutorial is that it demystifies “rerun” capability and shows how little you need to get started. It is also shows how you can streamline your workflow to the point when you can come to the untested field and walk away with working autonomous in less than 5 minutes of the field time.
Another “best” part, is how ridiculously large and inefficient is the auto-generated code. I hope that every team that tries it, will start researching ways of improving on it, thus the benefits of active learning.
You did very well answering tough questions and explaining how this method works. It looks like @Sylvie’s tutorial did great job at helping you and everyone else learn something new today.
And finally, to be pedantic, V5 only supports SD Cards with FAT32 file systems tested up to 16Gb and with 4Gb max file size, so no 20 day runs. Sorry to ruin your expectations. 