It's the fastest if it is impractical to set a keyboard shortcut for everything. And if it wasn't an editor, people sometimes just don't want to use a keyboard for whatever reasons.
They are more likely showing what the users intended to do. Changing the tool bars too much on the fly may distract the user.
Useful for some one-time related tasks. You could also use a tool bar. But it may take too much space if other tool bars are all small in your program. If there are too many functionalities that it needs a dialog, of course you don't want to close the dialog to do something very relevant, just because that functionality is more commonly used. So the more easily accessible functionalities might be repeated there.
To allow the users to explore all the features. If there are enough things the user could do, it's usually not very helpful to make sure all the functionalities are listed in any other single places, or they just take much space unnecessarily. (This have exceptions. You could group things properly in other ways, but that's usually not expected in some old programs.) If you only list things in the help files, people rarely read them. Some menu items might be never used, but at least they are simpler than most help files.
For some features such as copy and paste, users may rarely click in the menu. They only tell newbies that Ctrl+C means to copy, etc, and they are supported by this program. (Personally I don't understand why Google Chrome listed them in a way unhelpful in this case.)
It could also contain many disabled options, which are probably inappropriate in most other places. For example, before adding an image, you may want to tell the users that they could edit the image in your program. Otherwise they would open another program, edit and resave the image, just finding they didn't need to.
And many buttons on the tool bars doesn't have a visible text description. If your program is complicated enough that, someone is phoning another person asking about how to do something, menus and dialogs would be more reliable.
They could be all helpful to the same user. You may not need the complicated way if the simpler way could contain everything (which is indeed becoming more likely considering the increasing screen resolution). But if you need both the complicated and the simpler, you may need to repeat things in the complicated for one reason or another.
I just realized there were many bad things I know according to my answer. I'm not pushing those changes (They may have other considerations) but only to demonstrate the idea.
- Tool bars: The notification area items for only denoting a background service is running, which users aren't supposed to interact with often. Better there is another dedicated management window or menu for those services.
- Context menus: I remember a version of KDE which mixes the context menu of desktop and taskbar (don't know whether it is still the case). It should only use a proper menu and no context menu if it insists that they should merge them together.
- Menu bars: The Chrome way organizing edit options. A submenu with keyboard shortcuts displayed would be more helpful. Leaving most other items like normal menu items makes it look worse. And we know allowing strange things appear in the menu isn't invented by Google, as it was possible in old versions of Microsoft Office.
And a good example: There are many tabbed applications supporting moving a tab to a new window. But when there wasn't a menu option, some people (including me) got very annoyed by the "fact" it doesn't have such a functionality. But when there is the menu option, or we start to use a program that just doesn't work if there isn't this functionality, we realize the tabs could be dragged out quickly. And we then start trying this in other programs without this menu option.