Whenever the web site can simulate a reload, then it would be very fast (e.g., it would refresh the data shown without reloading everything else).
Whenever it can't or the user clicks reload again, the normal reload would happen.
A single page app can refresh or redraw just the portion of the screen that has changed -- and they can do it without even calling the server. This definitely makes web apps feel "zippier" and more like desktop apps.
If looking for new data from a server, a single page app can redraw just the portion of the screen where the data on the server is different from what's already drawn, and this also improves responsiveness.
Here's some more about SPAs in general [0] and an article I wrote about developing with web components [1] which is a modern way to build them:
[0] https://en.wikipedia.org/wiki/Single-page_application
[1] https://medium.com/gitconnected/getting-started-with-web-com...
Some users use it to fetch updates even when they don't have to, but they still get what they want. A site that automatically fetches updates can be unreliable, so you reload it, which also let's you check your internet connection and the server. If reload would be handled by JavaScript you would have to close the browser and open it again to be sure.
Browser caching can violate the stateless nature of HTTP, if the web site allows it to, but the user can still force-reload to bypass caching.
2. The user controls their browsing. Web apps that hijack navigation, history, or reloading take control away from the user.
In any case service workers can already do this, as another commenter mentioned.
Having been put in place it's script is fetched once a day to look for changes.
It is a very powerful concept and widely supported I believe.