Anywhere and everywhere. I know that's not a specific, helpful answer, but we're talking about an application architecture decision, and you can do almost anything in an MVC pattern, whether it makes sense to or not. I suppose you can say much the same thing about any framework strategy (or lack thereof).
MVC comes from the Smalltalk environment, where you would be running a, well, let's call it a desktop application, shall we? (That's an implementation detail; it could as easily be a "thin rich terminal" app on a client-server model.) The point here is that it's really easy to maintain a separation of concerns in an always-connected system. Your UI reflects the state of the model (which includes the in-memory representation of data objects/entities, program state, and the rules for data integrity and persistence) by observing changes in the model and updating as required. It also provides a means of interacting with the controller level -- nothing that you do in the view happens in the view, you just make controller requests that affect the model, and what happens to the model is reflected in the view.
Web apps can't really work that way. Instead of a monolithic, always-connected system, you have a client (the web browser and page) that spends most of its time disconnected from the server, and a server that spends most of its time dealing with other users, and forgetting all about you between requests. So to do the MVC separation of concerns, you need a framework that can manage which parts of each of the model, view and controller live where. That will allow you to separately develop the components (the web page design, structure, look and feel; the user actions; and the data rules), while the framework worries about how to implement them. That usually means adding code to the web page, having a "proxy model" on the web page for the user to interact with between updates that happen on the server, and so on.
As with any framework/architecture, you're trading off complexities. You get a clear separation of concerns, but at the cost of a system that does magic under the hood. It's not the magic that's a concern, really, but the complexity of the system it takes to do the magic. The more complex the application, the more sense it makes to break it down into separately-managed chunks, since that greatly reduces the complexity of the code you have to write and maintain. When you write your user actions, it's a lot easier to write "tell this InStockEntity that this CustomerEntity purchased it", then let the system below worry about reducing the number of InStockEntities and creating an UnfulfilledOrderEntity for anybody using the Fulfillment view in your shipping department than it is to write all of the code that updates all of the various tables in your database in your "Buy Now!" button on a web page.
But you also need to keep in mind that you have to awaken The Beast every time you make a request, as a result of the stateless nature of the web. So it might not be something you'd want to do with a simple, lightweight app. Or if you actually need to worry about ultimate performance—something that may be of more concern in some circumstances than in others.
