I've seen a lot of stuff that describes how it's done, but not a lot that tells WHY it's done. Is it just a way to keep the code readable, or is there a better reason?
MVC Framework – Understanding the Purpose of MVC
mvc
Related Solutions
I think you are looking at this in completely the wrong way. A GUI app and a web page are worlds apart so the exact same definition of MVC will never work for both. MVC is more about the ideal: separating certain parts of the app like display and logic.
In PHP (or the web in general), a View is the web page itself: the HTML output. It's not "live" as per your definition, but you simply click links to go back to the controller (i.e. another page request).
The Controller and Model is where things do differ, like you explained. In PHP the model tends to be the data layer, interacting with the database and so on. But it is still modelling the situation, and the controller still controls the application flow, if only once per page load.
So the name "Model-View-Controller" is perfectly logical, albeit a different implementation in GUI apps vs web apps.
You're going to have to embrace ASP.NET MVC in its own right.
There is no server code-behind. There are no drag-and-drop widgets, no plugins, and no leaky page life-cycle. There is no almost-wysiwyg: instead there is total, actual, complete wysiwyg. There is no SESSION; you'll have to live without it. There's no weird, busted markup. Best of all, there's no lies or deception: ASP.NET MVC embraces the web just the way it is, instead of pretending to be something else.
All of this is good news.
My advice?
Start thinking about everything as a CRUD operation, a series of user transactions. That mindset won't get you completely there, but it will go a long way towards MVC enlightenment. Serve a page, get a result. Serve another page, get another result. Save the result to a database. Serve a new page containing database data. Rinse and repeat.
Understand the importance of Model-View-Controller. Make views stupid. Make controllers thin. All of your actual logic goes in the Model, which becomes fat. Use ViewModels if you need them to separate View logic from Model logic.
The Controller is a patch panel, a railway switchyard. Treat it as such.
Get really good at working with simple HTML/CSS and Javascript. Then learn how to fill forms with ASP.NET MVC's donut holes (most likely you'll be using Razor to do that).
Learn Server-Side Views first. Then, discover the essential truth of ASP.NET MVC, that it can serve more than just views, and become enlightened. It can serve files. It can act as a web service, and serve JSON to a SPA framework like Angular, instead of serving views. It can do this better (and simpler) than its predecessor, WCF, ever could.
Best Answer
It's about Separation of Concerns. Basically, you want your software components to do one thing, and one thing only. If your components start doing more than one thing, code gets hard to read, things become more complicated than they need to be -- basically an app turns into a big plate of Spagetti Code.
The Models contain the business logic, represent the things in your application. The views present the data to the user. The controllers decide what to do with the various user actions. When you stick to that, the code is easy to read because things are as simple as possible.
MVC is a popular pattern, but it's not the only one out there. MVVM is also popular. As long as you separate your concerns, pick any design architecture that suits you.