When to dispatch events in a custom module?

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.