In my experience, a web application would have to be trivially small to not benefit from the organization and decoupling that MVC provides.
Perhaps a bit of explanation about the MV* family of architectural patterns is in order.
The MV* patterns concern themselves primarily with the User Interface. Their primary purpose is to provide decoupling between the UI and the rest of the application.
In Winforms and other event-driven UI, we create a user interface by inserting objects that represent form elements such as text boxes into a Form container, and then attach events to those objects (such as Click or LostFocus) to perform actions in code.
I've drawn a thick arrow between the boxes to represent the fact that both data and commands are passed back and forth; this creates a user interface that is tightly-bound to the rest of the application. Anyone who has ever built an application this way knows that it's difficult to make it large, because you quickly end up with a plate of spaghetti code.
To solve this problem, we add a Presenter (sometimes called a Supervising Controller) to the mix, creating Model-View-Presenter. This arrangement pushes most of the UI logic out of the View, and into the Presenter, allowing for better maintainability.
Notice that I've drawn a thin line between the Model and the Presenter, indicating that only data is passed back and forth, not commands. This provides some decoupling between the Model and the View.
Model-View-ViewModel is very similar, except that there's a ViewModel instead of a Presenter. This arrangement is seen most often in Windows Presentation Foundation and in Single-Page Web Applications (SPA) using an MVVM framework such as Angular. In addition to command and control, MVVM also concerns itself specifically with data binding.
Model-View-Controller is primarily associated with web applications. In MVC, commands aren't routinely exchanged between the Model and the View. Instead, the View is POSTed to the Controller using an HTTP verb, and the controller decides what to do with it. Most of the domain logic is pushed back into the model.
Because MVC still binds the view rather tightly to actual domain objects, you can insert a View Model to get some additional indirection.
This View Model is not a command layer, like it is in Model-View-ViewModel; it's simply a data translation layer between the model and the UI. A good example of this would be a ViewModel for an invoice, which would contain everything that you need to display and update an invoice, such as names, addresses, and invoice line items. This data would then map to actual Model domain objects, such as Customers, Products, Pricing, etc.
When to use them?