IIRC, the Rails ideology says that "Models should not know about any part of the application except for their own datastore." Even though the :after_create hook is the "Rails way", doesn't this violate their own practices?
Edit: basically, the question is "which process involves sending the email". It might be "creating a user," or it might be "using the 'create user' form". At some point you might need a more abstract solution, of course — see things like Listeners, DHH's Concerns, AOP or whatever you like. But the thing is, if you don't delay too long, you can retrofit your codebase with it, so don't worry too much.
Unless you're coding up a nuclear plant or storm barrier or the moon-carving laser. Please don't use webappy principles to code drivers for the moon-carving laser.
We then wanted to add the ability for admins to edit profiles, so we created /admin/users/[id]/profile. If the logic wasn't in the model we would have to repeat it in both controllers (the views can easily be reused by having the form elements in partials).
The thing that bugs me the most is how both the article and some responses here go into heavy absolutes. Different domains have different needs, and what is "readable" changes between them, not just by size, but by shape as well. And yes, shape and size might change as the app lives (my current codebase being a great example), but you can't really predict everything.
At some point though, your controllers are going to grow. Multiple code paths depending on the data submitted, depending on the current state of the application, etc. At this point, building service classes such as CreatesContact can become very useful, not to mention much easier to test and reuse.
Evan Light's article at http://evan.tiggerpalace.com/articles/2012/11/21/use-rails-u... advocates "Use Rails until it hurts" which I think is a very good mantra to keep in mind when working with Rails.
In short, use your head. There is nothing wrong with breaking out this functionality into two actions.
Imagine a situation where you want to bulk-create Users via script (or, simply, not via your controller "create" action). Shouldn't those bulk-created users get emails too? It depends on your business logic, hence, your model.
Having tightly coupled objects that depend on other classes in your application that you wouldn't expect is worse than having a little bit of business logic in your controller (or some service object), in my opinion.