Short Answer
The primary benefit of decoupling application logic from any presentation/external interfacing layers is to allow consumers to vary independently without duplicating logic. Therefore, the necessity of decoupling is dependent upon how many consumers your application will have.
Long Answer
Using Domain-Driven Design nomenclature, your question could be recast as "Why include an 'Application Layer' within your solution architecture?".
The Application Layer is intended to serve as the interface to the domain and infrastructure needs of your application, translating request and response messages into interactions with the underlying components. By 'translating' here, we mean the conversation of a logical message in some standard format into zero or more operations upon the underlying components. Ideally, a request to a "Fund Transfer Application Service", which verifies the input, instructs the domain to perform a transfer, persists the domain state, logs the operation, and notifies the world by calling a "Notify World Infrastructure Service", could be called by either a component or subcutaneous-level test, a Web Application, a console application, or be exposed as a Web service without modification. That said, the degree any given solution benefits from such separation of concern strategies depends upon the context.
There are, however, other factors which may lead you to want some degree of decoupling from the consuming interface aside from a need to service multiple consumers. For example, the ASP.Net MVC architecture tends to steer developers into grouping operations together for a given view/Web page. For operations that go beyond simple CRUD operations on a single aggregate root, Microsoft's design has a tendency to lead to controllers which lack cohesion with respect to the adapter role-stereotype they are meant to serve.
To explain further, while you might have a CustomerController who's actions are all about customers and nothing but customers, each action may require different collaborators to accomplish their goal, not all of which are needed for every operation. One action might need to save something to a database, another may need to send an email, and another may need to cache data or place something on a message queue. Just because all these actions center around a single aggregate root doesn't mean the role the controller is meant to play (i.e. adapter) is cohesive with respect to its own responsibilities. Ideally, a Web framework would take an inbound HTTP message and map it onto a command handler within the Application Service layer without requiring the Application Service Layer to take a dependency upon the Web framework.
Architecture theory and Feng shui motivations aside, it really all boils down to your need to reuse the application logic that you are going to either place in your Web page/code behind/controller/command handler. Typically, the first client that should consume your application logic is your executable specifications and the second is the production interface. Depending upon your approach to testing (none, user acceptance, isolation, etc.) along with the ease in which any framework dependencies you take on as part of the application logic implementation effort allow you to implement the specification's observations, this will often determine the degree of decoupling you want to include within your application.
