When you need to bundle activity together a much better approach is to move it out of the controller and into a dedicated class. It isn't practical to test a controller in isolation, but quite simple to test a PORO.
When you extract the activities into a class you are forced to name the behavior outside the context of some controllers "create" action. Testing, readability, and complexity wins.
We did consider the service object approach, as detailed early in the blog - for me, though, it feels wrong to end up with a bunch of service objects, each with a semi-random grab-bag of dependencies and responsibilities. One of our main aims was to reduce the random scattering throughout our app of various calls, because the coupling was making it hard to reliably effect change when necessary. Service objects don't address this, unfortunately. We still make use of them, but to my mind a CommentCreationService should only be concerned with creating valid comments - not with emailing or rewarding users.
I personally felt that their original code was not that bad.
You're quite right, in the original code it's easier to see at a glance what happens in that particular action. However, over the span of the whole application it's much more difficult to see, say, all circumstances in which an activity update is triggered, or all the ways a user might get a gamification reward for doing something on the site. It was precisely the growing complexity of our app that motivated this change; we were losing the ability to keep control of (and test) whole important features of our site, such as mailout logic, gamification, etc. and so forth.
As I say at the end, I certainly don't recommend this as a catch-all approach; you've got to know your app and be aware of the advantages and disadvantages.
