GET (and a few other methods) are defined as 'SAFE' in the http spec (RFC 2616):
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow
the user to be aware of any actions they might take which may have an
unexpected significance to themselves or others.
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, so
therefore cannot be held accountable for them.
This means that a GET request should never have any serious consequence for the user, beyond seeing something they might not want to see, but a POST request could change a resource that's important to them, or to other people.
I also don't think it should ever be necessary to redirect to a POST. Any action that needs to be carried out can presumably be done by calling a function within the server side code, or if it needs to happen on a different server then instead of sending a redirect containing a URL for the browser to POST to, the server could make a request to that server itself, acting like a proxy for the user.