No, because when you want to view the source you mean to view the source of this very document, not the source you'd get by asking to reload the page, it is often different.
If they wanted that, they'd have looked at the developer tools to begin with.
Many of you folks are completely missing the point. The world wide web took off in large part because it was incredibly easy to learn HTML, because with every webpage if one wanted to know how it worked one could just look at the source code.
How the page is currently being rendered, what state the DOM might be in... These things do not matter to someone trying to view the source HTML for a page. They're looking to learn about the HTML. They're not goimg to get that by viewing pre-digested DOM information.
Or a website I was trying to fix: the source in view source, and thr stuff on dev tools, never matched each other, even with JS disabled. in the end after days I gave up and the page is in production, crazy bugs and all, because I can't figure why on both chrome and Firefox the webpage end with lots of random "strong" and "span" tags that don't exist anywhere in the original source. The tags aren't even closed properly, some are never closed, some are closed multiple times.
There are edge cases where a bug is intermittent... and is masked by something on the client side, especially possible with browser plugins. In fact, plugins were the cause of 2 of these for me... Where some issue on page load was causing a bug, but then JS was changing the source away from what cased the bug, but a refresh wasn't guaranteed to have the same information (this was a fast changing log-viewer, for one of them) ...
So you end up not being able to capture the init state of the page... but the bug wouldnt show up without JS enabled because the error is in the JS...
Not common case... but it seems like fetching from the server is MORE work for no reason when the data is already there...
Hence it's acceptable to request the document from the server when opening 'View Source'.