Those two are closely related to each other, mind though that Task-based approach will limit you to only a few overridable functions, such as Initialize(), Run() and Destroy(). Whether Message-based approach lets you expand when you need without the necessity of adding extra functions to your Message interface class, Task-based approach fails to provide it in an easy and proper way. An example would be adding an extra message definition to your enum', and the need to add a pure virtual function the the ITask class, which is hardly worth the effort of implementation in ALL of the derived classes.
There are work-arounds to that problem, such that you define not PURE, but just virtual functions in your Task class, or having one generalized function to do all the extra work in.
Also it depends on the sort of the project you're working on. If it may be an SDK, I don't see anything wrong with tightly coupled code, however if it is a toolkit, it may render useless and even wrong.
At the moment, I'm taking the Message-based approach, the Subscriber pattern, however I'm also considering using Task-based approach in a tight game loop for the engine' work, however this might be a little overkill. :)

Standard non-message loop for me. Requiring the controlling app call a function or two in the main loop isn't exactly a terrible coupling burden.