The description on the page to which you linked seem to be fairly descriptive of their intended purpose:
A 302 redirect indicates that the redirect is temporary -- clients should check back at the original URL in future requests.
A 303 redirect is meant to redirect a
POST request to a
GET resource (otherwise, the client assumes that the request method for the new location is the same as for the original resource).
If you're redirecting a client as part of your web application but expect them to always start at the web application (for example, a URL shortener), a 302 redirect seems to make sense. A 303 redirect is for use when you are receiving
POST data from a client (e.g., a form submission) and you want to redirect them to a new web page to be retrieved using
GET instead of
POST (e.g., a standard page request).
But see this note from the status code definitions -- most clients will do the same thing for either a 302 or 303:
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.