One thing that was not mentioned is the intent of each of the calls. I recommend searching the forum for a more complete outline, but it important to realise that these are different pieces of functionality and are not necessarily interchangeable.
Take as an example two common pieces of functionality.
The first is to display an error page when some processing fails. In this case, you can put any additional information on the request, forward to the display page, and everything works fine. The client's browser still has the same URL so if they reload the page it will repeat the previous step.
The second is to submit some data then send back to a menu. If you use forward, the URL doesn't change, so if the user refreshes the screen it resubmits the data! In this case, it is better to process the data then sendRedirect to the menu page. This forces the client to send a second HTTP request, asking for the menu page.
In the first example, if you use sendRedirect rather than forward you can't place information on the request context, and information gets lost once the new request comes in. You could place the information on the session and still use sendRedirect, but placing request-scope data on the session is a recipe for disaster. This is another story.