One of the ways we avoid the "out of the blue" surprise is to always read the "Perform upgrades here" link by clearing the browser cache and refreshing the main page of the dashboard, then clicking on "Perform upgrades here". Doing this will show all the "new code and commits" and so there is no "out of the blue" upgrade surprises.
However, I realize that for people who run Discourse in "single container" mode that they may not upgrade often, and so reading many hundred (potentially) commits would be a lot of work.
We avoid this issue by always (and often) upgrading a "standby" container which is not "live" and we switch the "standby" to "live" after upgrading "standby" so we have nearly zero downtime (actually, zero to be honest, for the most part) when upgrading.
However, this method is not flawless in the case of a major DB upgrade like moving from PG 11 to 12 or PG 12 to 13 (because we have only one data container), so that is why it's good, even in our setup, to review the commits on the " Perform upgrades here" link (and the commit history page on GitHub) before upgrading. Honestly, I generally do not upgrade until I have read this page; being a person of "low risk" and "not a fan of surprises". We upgrade nearly every day, to be totally honest by bootstrapping a new container and switching to it "live" as described above.
Generally speaking, if you review the meta team’s commits, they are mostly benign “non-breaking” commits (my phrase, not an official term), changing some specific JS code (EmberJS), bumping a gem version or other lib, and making other “non-breaking” feature changes. However, changing a full DB version can be potentially “breaking” (downtime can happen) as well as some other underlying Rails application code, so we tend to pay close attention to all this type of “potentially breaking” (my term, not an official term) code before bootstrapping a new container. Of course, this is only because we are “self hosting”. Those hosting with Discourse, and supporting them directly as hosted customers, have all this taken care of for them!
Discourse does a truly stellar job to provide all their code changes on GitHub and these are easily reviewed. In addition, the meta team will normally announce a major change here in the "announcements" category, and so this category is a good place to take a quick look for people who do not want to be caught off guard by a major, potentially "breaking" upgrade, and who do not have the interest to read the code commits.
Personally, I like reading the Discourse code and commit history, especially the Ruby code, since I'm a Ruby fan and have and do learn a lot from the meta team by reading their open source code. Sometimes I see something in code I do not fully understand and I study that code and check online references until I understand it. Of course, for folks not interested in code, that is not going to be "fun" like it is for techies like me.
The bottom line is that to avoid being "surprised, out of the blue" by a major change, for self-hosted users, is to take either take a quick peek in the "announcements" category before upgrading and to consider reading the commit history as well. This might sound a bit "too techie" for those self-hosted sites not interested in code; so at least try to get into the habit of reading the announcements before upgrading.
Hope this helps.