I think your option number 5 is best, but with some slight tweaking:
Your ViewModel should have a property that indicates whether the data can be updated, or not. Perhaps a "CanOverrideLateFine" boolean property.
Whatever is creating the ViewModel (your Controller, or more likely a business service that your Controller delegates to) is responsible for evaluating the business rules and setting that property. Not the ViewModel itself.
The View will then inspect the "CanOverride" property and determine how to properly render for the user. It may be as simple as enabling or disabling a form field, but it may be something completely different (maybe not even rendering the field, or supplying a completely different visual element).
EDIT: To summarise, I think understand where you're coming from - at first glance, the ASP.Net MVC framework seems to have (too) many parts, and it's difficult to start understanding it. Having said this, I'd argue that you're looking at this wrong. ASP.Net MVC is not a particularly heavy MVC framework (you should compare it to PHP MVC frameworks to be fair), but yes, it is very much conventions-based. There is a lot of good reasoning behind that design choice, and your first priority in learning the framework would be to learn its conventions, and perhaps the reasoning for them. If for some reason you absolutely want to go deeper, the framework is open source, and you can dig into it here.
I can just skip frameworks altogether, and toss random PHP along with my HTML on a single file and make it work
Well, not with an MVC framework (even in PHP). You're going to at least have a model, a view, and a controller. Those are a bit of a minimum, so I'm not really sure what you're looking for here; it's an apples and oranges comparison.
After that, there's going to be a few other files that you will probably need; such as configuration for the routing, etc. This is fairly standard and comparable to PHP MVC frameworks.
If you want a "single page" model, you could try WebForms, although that technology typically tries to move logic into a separate "code behind" page. I'm pretty sure you could skip the latter, however, and have .aspx files logically identical to .php files sitting there.
Do I really need to create a whole bloat of files and folders...
The default VS project template does tend to copy a lot of potentially unnecessary stuff (scripts, etc), but you could remove most of those. Again, you will probably have a minimum number of things there. Do these really cause you major worry? Have you seen what a Symfony installation looks like?
... for the sake of convention?
Convention is a great thing. The concept is called "convention over configuration", and for most non-trivial projects, it is wonderful thing. It stops people from reinventing things, and gives standards that should be followed.
Since you mention this is a learning exercise, I would suggest that you stop worrying about these things too much. ASP.Net MVC is very much about convention, and you are doing yourself a disservice by trying to work around those. In fact, to learn MVC, you should learn the conventions as much as any of the internals.
Best Answer
Stateless means that HTTP doesn't have built in support for states; e.g. you can't store if a user has logged in or done something else.
The most common solution is to use sessions to overcome that problem. This means that you have to be able to include a session identifier in each response or request. This is either done by creating a session cookie or by including the session identifier in all links.
WebForms tries to make all that transparent (using ViewState) while MVC forces you to handle it manually.
In your example you mentioned Buttons and TextBoxes. The easiest way to let them maintaining their state is simply to stop posting back the entire page. MVC got excellent support for ajax (through jQuery) and I suggest that you use ajax if you just want to do something on the current page.