The MVC design pattern was initially developed before the Web was a thing. It mainly addressed architectural problems that applications with a richly interactive GUI had. The main benefit was Separation of Concerns. Something had to handle business logic and persistent data storage (the "Model"). Something had to handle the presentation of the use case to the end user (the "View"). And something else had to coordinate the use case and initialize the whole thing (the "Controller').

It was determined that events were the ideal medium of communication between these three components, because it decouples the Model, View, and Controller. You will find that "decoupling" and "Separation of Concerns" are complimentary concepts. In fact, you really cannot "separate your concerns" without decoupling components. This is crucial to understanding why web frameworks, which have no persistent user interface, continue to use this design pattern. Don't get too hung up on events and persistent user interfaces. Events were an artifact of building an application with a persistent UI rather than being the foundation of the MVC design pattern.

Even though the Web has a stateless UI, it is still desirable to separate business logic (the "Model"), presentation logic (the "View"), and use case coordination logic (the "Controller"). Since the Web has a stateless user interface, events are replaced with HTTP requests — an artifact of building an application with a stateless user interface. The main benefit of the MVC design pattern — separation of concerns — is still realized on the Web, regardless of how the UI is implemented.

As a side note, Microsoft's first widely-used web framework (ASP.NET WebForms) attempted to literally turn HTTP requests into application events. A hidden form field on each page contained a serialized version of the "view state". Upon POSTing back to the server, the view state was rehydrated from this serialized form field. Then based on the name of a button, the framework would trigger a simulated UI event just like you would expect from a persistent user interface. The framework attempted to hide the messiness of a stateless UI for people already familiar with MVC in desktop applications. It turned out to be a leaky abstraction, though.

The MVC design pattern was initially developed before the Web was a thing. It mainly addressed architectural problems that applications with a richly interactive GUI had. The main benefit was Separation of Concerns. Something had to handle business logic and persistent data storage (the "Model"). Something had to handle the presentation of the use case to the end user (the "View"). And something else had to coordinate the use case and initialize the whole thing (the "Controller').

It was determined that events were the ideal medium of communication between these three components, because it decouples the Model, View, and Controller. You will find that "decoupling" and "Separation of Concerns" are complimentary concepts. In fact, you really cannot "separate your concerns" without decoupling components. This is crucial to understanding why web frameworks, which have no persistent user interface, continue to use this design pattern. Don't get too hung up on events and persistent user interfaces. Events were an artifact of building an application with a persistent UI rather than being the foundation of the MVC design pattern.

Even though the Web has a stateless UI, it is still desirable to separate business logic (the "Model"), presentation logic (the "View"), and use case coordination logic (the "Controller"). Since the Web has a stateless user interface, events are replaced with HTTP requests — an artifact of building an application with a stateless user interface. The main benefit of the MVC design pattern is separation of concerns. This is still realized on the Web, regardless of how the UI is implemented.

As a side note, Microsoft's first widely-used web framework (ASP.NET WebForms) attempted to literally turn HTTP requests into application events. A hidden form field on each page contained a serialized version of the "view state". Upon POSTing back to the server, the view state was rehydrated from this serialized form field. Then based on the name of a button, the framework would trigger a simulated UI event just like you would expect from a persistent user interface. The framework attempted to hide the messiness of a stateless UI for people already familiar with MVC in desktop applications. It turned out to be a leaky abstraction, though.