Hope this isn't TL;DR
I seem to be having trouble either making my point or understanding the responses.
No, my use case is what I would consider the most common case, where the device is intended to remain fully active 24/7, whether battery or line powered. (For this specific case, it's a thermometer that is line powered, possibly on a UPS. The step control widget on pin V2 allows me to change a temperature alarm set point). Sorry if my "sleeping during a meeting" analogy was taken to mean I'm putting my device into a sleep mode. By "sleeping during the meeting" I meant the device lost connection to the internet.
I guess powering down the router that provides the WiFi internet connection to the device is a bad example, which could be confusing because it involves powering stuff down. Instead, let's say something further upstream (offsite) goes down to prevent internet access to the Blynk server, but the Wifi link between the local router and the device, and the device itself, remain active (and nothing goes to sleep). Note that at no time does the internet link between the app and the Blynk server go down.
I want to be able to change the value of the step control and know that the device will start using this new value as soon as possible. If I change it while the internet link to the device is down, obviously the device can't be told to change it, but I want it to update as soon as the link comes back up.
If you follow the examples, where an isFirstConnect flag makes it so Blynk.syncAll() is only called on the first connect after device power up or program reset:
If the device's internet link goes down after the first connect, and I change the value using the step control widget during that time, then Blynk.syncAll() isn't called when the internet comes back up, so the device's V2 value won't change unless I change it to something else and then back again in the app after the device is back online.
If you eliminate the isFirstConnect flag logic, so that Blynk.syncAll() is called every time BLYNK_CONNECTED() is invoked:
If the device''s internet link goes down after the first connect, and I change the value using the step control widget during that time, then Blynk.syncAll() is always called and V2 gets back in sync.
This meeting analogy you made the first time is not pertinent. "What did I miss?" (meaning Blynk.syncAll) isn't asked every few seconds (meaning frequently) in either of the above two cases.
Think entering a meeting late (meaning I've changed the value in the app while the device was powered down) then asking "What did I miss?". Later, you leave this meeting in progress to take an important phone call (meaning the device's internet connection goes down but the device is not powered down, reset, or put into sleep mode, and I change the value in the app while it's down) then returning and again asking "What did I miss?".
Would you want to be told:
We can only tell you what you missed at the start, while you were late, but we can't tell you what you missed during your phone call.
(This is how the examples using isFirstConnect work.)
Or would you want to be told:
Here's what you missed during the time you were late, and here's what you missed during your phone call.
(This is how eliminating the isFirstConnect logic works.)
So I still have the same question about this example (which is also widely used elsewhere, such as here):
Why, for most normal use cases, would you want to only do a sync after powering up or resetting, instead of also syncing after re-establishing a lost connection? (Given that the app can change pin values at any time, even when the device is offline either powered up or not.)
It just seems to me that the behaviour of the examples (syncing only on first connect, not on subsequent reconnects) isn't what would be desirable for the majority of cases (and specifically mine).
Again, sorry if I've gone into too much detail and been repetitive to state my points.