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?
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.
The actual purpose of MVC is to separate your views from your controller and model. In other words, it is a design pattern is a structure for keeping display and data separate to allow each to change without affecting the other. By saying so, it is mostly used for GUI stuffs. Thus it essentially contains three things. The Model contains what is often called business logic, or all the data and information manipulated by your system. The View contains the objects that display the data, and the Controller manages the interaction with the user and mediates between the Model and the View.
In many modern GUI toolkits, view and controllers are somewhat inter-related and thus cannot be fully separated. For example, a button is a controller but it needs to be displayed in the screen.
Thats a big question I don't have time for that big of an answer, so I'll try to keep it short.
The primary reason is like you said for keeping the code readable and manageable. The separation of these main components model, view and controller help to create more reusable code that is easier to understand because each piece has a distinct purpose. The model representing the objects or data within the system and containing the code for the actions that can be performed on those objects. The view of course encapsulating the layout and design that allows you to view that data. And finally the controller that allows you to navigate from view to view, action to action.
If you have ever dealt with a large system of code that married the three of these together, you will have seen the typical copying of large chunks of redundant code that was not quite what was needed for the next task. These models are built in such a way that they are more generic making them more reusable than it was inline. That is you dont have SQL statements scattered throughout your scripts instead it is consolidated. The same is true of HTML being scattered in code, very undesirable and hard to edit and maintain.
Hope that helps.
There is also other things I haven't seen mentioned here. Yes, a design pattern prevents the problems and difficulties of spaghetti code. No longer do you have to deal with a chunk of code, adventuring through hundreds or thousands of lines to get to the piece of code you want. But there are other reasons as well: Since your code is divided into multiple sections, communications of developers will have an easier time, addressing and therefore solving a problem. A design pattern also helps developers to program accordingly to DRY. An example of this is the layouts in Laravel, which helps you not using the same piece of html code again and again. Make sure to check out this link for more info: Design Patterns