This is a question regarding both Magento 1 and Magento 2.
I understand that, as a good practice, 3rd party modules developers are encouraged to dispatch events in their custom module to make it easier to work with other modules.
I would like to know:
You're not going to find a good, clear, deterministic answer here. By and large, you should dispatch events in your module where you and your users need them -- if you can't think of anywhere they might be needed, you don't need to dispatch them. Magento itself emits so many events at so many different places (controller pre/post dispatch, any crud operation, etc) that your module will already dispatch a number of useful events without you doing anything.
Since that's unsatisfying, you'd want your module to dispatch an event when there's some action your module takes that your users might want to add items to, delete items from, change, or take a separate action independent of the original action. For example -- Magento has a visitor_init event that's not part of its standard suite of auto generated events. This event allows programmers to modify the visitor objet before Magento logs data. These was no way the original module developers to deterministically know this was where an event needed to be added -- it likely came from feature requests and/or interviews with system users. Know what your users want, and if its not possible/practical to build out a UI/UX to let them do it via the admin, add an event hook so another programmer can do it for them.
Less sexily, adding events can also be a cheap way to enable developers (either your users, or even your team) to add some functionality into a gnarly bit of code that everyone's afraid to touch. Plop your dispatchEvent call in the middle of the code, hook into it, and you can add your functionality without disturbing the code in the original scope. [Editor: Also you should refactor that awful code at some point]
Performance wise, adding an event to dispatch will depend on where you add it. When you call dispatch event, Magento needs to make a few extra PHP calls, query the configuration for any configured observers, and then call the observers. Done once, this is a cheap addition in the scope of a standard Magento dispatch. However, done repeatedly, (say, before every block render) this may add up. There's no good rule of thumb here -- as always the right answer is profile.
Finally, w/r/t Magento 2, it's still too early to say. All of the above still applies -- however the plugin system adds a few wrinkles. Plugins are, from one point of view, a way to create event like behavior for any public method call in Magento. In theory, if you're designing your classes correctly, you shouldn't ever need an event. However, in practice, dropping an event into a bit of protected or private method code will be a tempting solution for Magento developers when the alternative is a long refactoring process. Also, creating a specifically named event can often create a friendlier experience for developers using your module.
Hope that helps!
For Magento 1, good times to throw events are before and after all CRUD operations and before and after rendering. Many of these are already provided by the abstract classes in the core, so in practice not that many third party events are needed.
With Magento 2 the situation is different. Because public method calls can be intercepted with plugins, custom events are no longer needed.
When designing classes, instead of simply making every method public so it can be intercepted, it is better to decompose a large class into multiple smaller classes.
Each of the smaller classes then might have one or two nicely named and interceptable public methods.
Like Vinai said, before/after CRUD operations. Another important place to dispatch events is in adminhtml form blocks (if applicable). That way you can add new input fields if you've added custom attributes/fields without having to rewrite the admin form blocks. (This is for Magento 1). See example
Inside of Magento 1, you can leverage events through the auto-fired events that occur. All you need to do is set an $_eventPrefix and $_eventObject properties on your models. Also, you have custom fired controller events through the 'controller_action_predispatch_ ' . $this->getFullActionName() and 'controller_action_postdispatch_' . $this->getFullActionName() events on the controller automatically. Those can get you most of the way there.
For Magento 2, keep your methods public inside of your classes. This allows plugins to intercept your methods. If you follow this, you won't have to create any custom events.
I hope this helps!
