The Live Updates setting should be a sticky preference.
When you update the setting on the page, it should remember it on future page loads and sessions.
TBD, whether each page (RecentChanges and Watchlist) is separate, or there is one overall shared sticky setting.
What is the ramifications of this for performance, especially for big wikis like enwiki?
If the live updates feature is used temporarily in those wikis (users click it for a few minutes and then turn it off) the feature may be redundant or even unuseful if the user forgot to turn it off in the last session. And if we start having a lot of users having this on by default as they load the page, would that not severely affect performance?
I'm agnostic as to whether this makes sense, I can see merit in both having it as a sticky preference and not, but I'm wondering if we might want to check into setting it as preference per wiki for performance; having it sticky in smaller wikis but not in big ones...?
It seems that performance was considered differently in the development of live updates. The implementation in MW 1.40 sends a request once per 3 seconds (by default, configurable with $wgStructuredChangeFiltersLiveUpdatePollingRate) to see if there are new changes. The UI button merely decides what to do with the result: if the button is on, new changes are displayed automatically and the polling continues; but if the button is off and a new changes arrive, the polling stops and a link "View new changes since ..." is shown.
It works on enwiki, because the edit frequency is very high and the button is off by default, so the polling stops pretty soon. On the other hand, the live updates feature can be devastating to small wikis regardless of the UI button state, because of the initial polling before a new change is detected.