If it is only a second or two then maybe the wording needs to be changed in the options as it currently states it "Causes major startup delay with progress bar".
I've tried enabling this in the past and did notice a considerable (10-12 second) startup delay on the computers I was testing with but maybe this has changed now.
Added (at the risk of being further black sheeped):
While I understand d7 and dSS have many ways to skin a cat, and love that fact, I also find some of the ways might not be the best methods for my business. Your business is not mine, and everyone who uses these products all use them in different ways, that is what is so great about them. Please don't think I dislike anything you do, I respect your help to the community and opinion, I just don't feel the same in kind.
If updating on heartbeat once a day is enabled and works for must customers why also force an app update and config update on every start? To be as seamless to my customers as I can I was merely suggesting for a way that the end user could trigger these updates. Currently I ask them to use the scheduled task, which is end user initiated, and I will continue to do so when needed, I just thought some easier method would be more useful than having every end user have an unneeded startup delay.
If you feel the current methods are all that is needed then we can all carry on and consider this closed, but in my opinion updating on every start could be replaced with an option in the gui to check for updates. This mixed, mixed with heartbeat updates, could easily keep everyone updated. If that seems redundant then doing an update on startup is the way to go and heartbeat updates seem redundant.
I've seen very few apps update on start and then not present a way for an end user to initiate an update after it is started. Even D7 and dSSMC allow for checking for updates after they have started.
If startup checks are enabled, on heartbeat does it update version and config too? If so maybe I just stick with that and not worry about it.