This pattern does solve two problems.
All scripts that process POST requests must always end up doing redirects. A naming convention that allows to distinguish between POST and GET scripts should be used.
The consequence is far reaching and much more important than solving the problems.
Separation of data displaying and application logic.This looks a bit like model/controler, but is much simpler. The problem of updating the views if the model is changed does not exist.
While displaying of the data is done by GET requests all 'true' user input is processed by POST requests. 'True' user input is input that necessarily changes server state. Example: Search requests are not considered 'true' user input.
The main task of the POST scripts is however not, to change server data but to decide where to go next. Example: A script processing adress data changes the data used for form persistence so that some error message is displayed and redirects to the input form, if the adress is not valid. It redirects to an OK page, if validation succeeds.
Remark: Inbetween I have found out that the above is a HTTP aware variant of what the Java people call JSP model 2 architecture. I do not grok where the objects get in, but I am only a poor guy who can use vi. The above article indeed states:" ..., servlets are more suited for back-end developers because they are often written using an IDE -- a process that generally requires a higher level of programming expertise. ". Phew, and I thaught those IDEs were for whimps.