This has been a cause of frustration for me on many sites like IRCTC, Online Banking sites which wont allow Back, forward or refresh. If you do you would be logged out and you have to login again. What I don't understand is what concern had there been in their mind to have such terrible "feature".
A common reason for this "feature" is that a site tries to keep some state of the current session on the server side.
That desire to track "conversation" state on the server side often comes from trying to write a Desktop-like "rich client" on the web (as opposed to embracing the web as the chaos it is). To be fair, this mostly happened in a time when the concept of a rich web application wasn't as well-understood as it is these days.
For example if a site provides a multi-page wizard and tracks where exactly you are and what answers you have given, then supporting back/forward in a sane manner becomes complicated (because some operations don't get communicated to the server at all).
This complication sometimes goes so far that sites outright ban forward/back. As you noted, that has obvious usability problems.
Modern web applications (notably those written in MVC or similar) have no need for such navigation methods as the process flow is driven by the on-screen assets.
Much of the interface of modern browsers is however still very much geared towards Web 1.0 style web sites where the content is static and there isn't so much need for maintaining state.
Even knowing all the above is true, I agree that it is something of a pain to have such features taken away when they're now so natural to us.
I'd take a punt that future frameworks will have some way of hooking on-screen assets into browser back/forward/refresh buttons in a similar way to winforms apps where buttons could be assigned to the Enter and Escape keys.
An alternative could be for browsers to (somehow) detect the underlying framework and hide buttons not supported by the web application interface.