I see a lot of MVC variants. The original I know of comes from Smalltalk. The model represents business and views present parts of the model to the user. Controllers handle events from the user. The objective is to isolate the model from its surroundings, in order to promote reuse of the model. Therefore it follows that:
a) the model knows not of the controller nor the view
b) the view knows the model
c) the controller knows the model
d) the controller knows the view.
In Smalltalk, it was very uncommon to create bespoke controllers, you used the ones that were there. They were tied to input channels, not applications. So you create your model and your views and tie it together in an app. The confusing part is that once a controller updates part of the model, the model should trigger the views to update. This was done through a 'broadcast'. It's a bit like a publication/subscription or broadcast. The model just says 'I've changed' and the views should then update with the latest model data by accessing the model. I forget where that is handled, but I think you do that in the setup where the views/models and controllers are tied together. It's been a while. But the rule was that the model never knew the view instances and did not know if any of the views updated itself.
An excellent remark was made on tiering, the original MVC (before it was even called a pattern), was a single large blob app environment. You can apply MVC to a front-end and back-end, and in each case the model is somewhat different. But on the basis of the original idea, the model of the back-end would be one you'd want to isolate from its context more than the model in the front-end.
So I would not think the controller is the perfect place to place business logic. I would say it's the model. I used to work for an IT company that found the MVC model lacks expressiveness and they created the 5-component model. (way back in the 90's) It is somewhat like the MVC model, but has a spot for data storage (i.e. the generic bit of your ORM or DB access code) and a spot for delegation work, and works more intuitively in practice.
MVC is not a bad pattern, but as with all patterns, their usefulness really depends on what you need the benefit to be. MVC's benefit was to allow you to yank model classes from one app and put them into another, without having to drag other stuff across as well. Basically business logic should not be tied to a specific application. Views are by definition tied to an application. So don't tie business logic to views. Same for controllers, essentially commands and some business state changes. The commands need to be responded to and business state changes sent to the model. So it's fine to bind input/output to a model, but don't bind the model to particular input/output so you can leverage the model. After all, reuse is best if I can simply create a class and tell it 'do this'. So MVC tries to help you make pure business classes. Not bad for 1969