Cut and paste of my comment that was suggested I make it a full answer. I have added in a bit more here to actually try and flesh it out into an answer.
Yes, plain and simple.. Communication needs to happen and while there are situations where 'Are we there yet?' type of polling is required, you generally are wasting time having things check to see if they should be doing something else, when you can have them react to things they are told to do... Plus... a well defined communication pathway between objects/systems/modules helps significantly in multithreaded/process/core/computer setups
Also, over on Stack Overflow I gave a general high level view of an event messaging system I have used from school into professional gaming titles and now non-gaming products, refined a bit each time to their specific usage of course, hehe..
EDIT: To address the question in the comments of how do you know which objects should get the message, the objects themselves should Request to be notified about the events. Your EventMessagingSystem (EMS) will need a Register(int iEventId, IEventMessagingSystem * pOjbect, (EMSCallback)fpMethodToUseForACallback) as well as a matching Unregister (making a unique entry for an iEventId out of the object pointer and callback). This way, when an object wants to know about a message it can Register() with the system. When it no longer needs to know about the events it can Unregister().. Clearly you would want a pool of these callback registration objects and an effective way to add/remove them from lists (I personally have used self ordering arrays (fancy way of saying they track their own allocations between a pool stack of unused objects and arrays that shift their sizes in place when needed) for the most part).
EDIT: If you want a completely working game with an update loop and an event messaging system you might want to check out an old school project of mine. This link is also in the stack overflow post on this topic linked above.
Hope this helps clear up your latest concern :)