I've never understood the pattern of separating out services, controllers and directives into different modules. Your post controller is probably going to need your post service, so why put them in separate modules? Makes more sense to have a post module with your WYSIWYG directive, post service, post controller, etc.
Every time I see it I just wonder aloud, what problem did you think this solved?
I think it was such a ubiquitous pattern in tutorials and apps early on that it became a norm people didn't question. As the author mentioned, it isn't really something that matters too much until you really start to build a complex app.
In my own experience, I've found taking such a modular approach too early on can actually hinder productivity as I find myself spending too much time on boilerplate and figuring out if, for example, this service REALLY belongs with feature X or feature Y.
I think modules become also really powerful to build and/or extract the framework that your app needs. In other words, distilling your framework out of your app.
I look at them as a way to extract those building blocks that support the business logic in your app such as a data store or driving app state through routes (whether you roll out your own or use third party libraries).
Even if you rely on third party libraries to fill those gaps, I like having my controllers/services/directives not to depend directly on them. For example, in the last year I've transitioned from ng-routes, to ui-router and finally settled with dotJEM/angular-routing [1]. Something similar happened when using $resource, then switched to Restangular, to finally use a thin data store on top of $http [2].
Having that code in a separate layer helped identifying service boundaries within the app and made it easier to replace them when needed.
Every time I see it I just wonder aloud, what problem did you think this solved?