I think the problem is that "business logic" is too vague a term, spanning what can be called both "rules" and "behavior." What you've cited -- "emails must be unique" -- is a business rule and belongs in the model, since only the model can enforce a data invariant like that. But take something like "new users are sent a welcome email." Would you put that in the model? Personally, I wouldn't (my User model is supposed to know about the mail service? really?). That fits into the class of behavior and belongs in a controller.
Put another way, when business rules change, you change your models. When business behavior changes, you change your controllers.
Really, it's a natural extension of the concepts of a database. Constraints and fetching information happen in the data layer, same as always... we've just moved some of the data layer into the model and out of the RDBMS.
Your actual procedural stuff that's actually deciding what to do to and with the data doesn't go in the database (stored proc fanboys be damned), and likewise doesn't go in the model.
Well, you are right, the model should not send the mail to new users. There should a way for the mail service to poll the model for emails to be sent. So the business rule here is still coded in the model. Say you want to also send the same email to old inactive users, you should just need to change the model, add a new business rule.
If you add such rules in the controller, you have to split your rules in two places, which is bad.
Ideally, I always thought that business rules should be a kind of "config", or more accurately a set of files written in a mini-domain language, that would be readable by PMs. Then it would be the job of the model to interface this set of rules with the controller.
So no, business rules and logic and whatever do not belong to the controller.
>But take something like "new users are sent a welcome email." Would you put that in the model?
Yes, 100% absolutely, no question.
>That fits into the class of behavior and belongs in a controller.
The controller is just to handle input, it has nothing to do with behavior. This is one of the key misunderstandings that differentiates between MVC and the weird mess rails calls MVC.
"Controller" is one of those terms that has meant a lot of different things at different times and in different systems. I agree that the same code asset (whether it's called a controller or whatnot) that handles user input should not be responsible for implementing a rule like "new users get emailed." At the same time, I also don't think such a rule belongs in your model layer. It should go in its own class (sometimes called a service, sometimes also called a controller). So the controller-managing-ui calls the controller-defining-behavior to make changes to the model.
Put another way, when business rules change, you change your models. When business behavior changes, you change your controllers.