The core idea is: you want to keep a firm separation between UI code (view) and object-oriented business logic (model).
Other objects will need to reuse your model as your application grows; UI code will clutter that reuse. For example, your business logic should return an array of Customers, not an array of UI labels. The business logic shouldn't directly refer to UI code at all.
In addition, you'll probably want to reuse some of your UI code in multiple contexts. A fancy resizable scrollable table shouldn't directly refer to Customers, because you might also want to use it to display a list of Purchases.
But if the business logic shouldn't directly refer to UI code, and UI code shouldn't directly refer to business logic, then you'll need some code to bridge the gap. That's the controller.
But this idea still leaves a great deal open to interpretation. How much work should the controller do, vs. pushing that work to the model or the view code? What's "business logic" as opposed to "view logic"? Should the controller code be a single object? Is your view logic complicated enough (and reusable enough) to justify separating it out into another object (a "view model")? If you never write any reusable view code, do you even have/need MVC? All of these questions are unresolved by "MVC."