Not true. Like I said in my response, this is something that can be done in Rules.
rule "Command device to restored state"
when
System started
then
MyDevice.sendCommand(MyDevice.state)
end
There are many cases where one does not want to restore a device to the state it was in when OH went down. Cases where doing so is not just undesired but can be down right dangerous. For example, if my garage door opener happened to be up when OH went down I certainly don’t want OH to open my garage door when it comes back up. Far better to have a temporarily inconsistent state and then through Rules or based on setting of the bindings to poll for the current state of the device and update the internal OH state to match the real world.
Applying the policy of “do the least amount of harm” it is far better to have a temporarily inconsistent state internal to OH that will eventually (often within seconds) get updated to match the real world than activating devices to make them match OH’s internal state on a reboot.
And where it makes sense you can use the rule above to force the device into the restored state.
As for why would we use the feature? Nothing forces you to. But 99% of the time when OH restarts nothing changes so when OH comes back up its internal state will match the real world. Using restoreOnStartup lets you avoid a whole lot of error checking in your rules because you can ignore the case where an Item is Undefined because the restoreOnStartup guarantees they will have a state. Sometimes one will have Items that represent a state (e.g. alarm clock time, flags, etc.) which should be restored before any rules run. And, like I said, any inconsistent state will remain inconsistent for only a short period of time except in cases where a user has devices that never report their status. Finally, if you did want to force your devices to match their restored state the only way you can do this is through the use of restoreOnStartup.