Why refresh CSRF token per form request?
For the reasons already discussed, it is not necessary to generate a new token per request. It brings almost zero security advantage, and it costs you in terms of usability: with only one token valid at once, the user will not be able to navigate the webapp normally. For example if they hit the 'back' button and submit the form with new values, the submission will fail, and likely greet them with some hostile error message. If they try to open a resource in a second tab, they'll find the session randomly breaks in one or both tabs. It is usually not worth maiming your application's usability to satisfy this pointless requirement.
There is one place where it is worth issuing a new CSRF token, though: on principal-change inside a session. That is, primarily, at login. This is to prevent a session fixation attack leading to a CSRF attack possibility.
For example: attacker accesses the site and generates a new session. They take the session ID and inject it into a victim's browser (eg via writing cookie from a vulnerable neighbour domain, or using another vulnerability like jsessionid URLs), and also inject the CSRF token into a form in the victim's browser. They wait for the victim to log in with that form, and then use another form post to get the victim to perform an action with the still-live CSRF token.
To prevent this, invalidate the CSRF token and issue a new one in the places (like login) that you're already doing the same to the session ID to prevent session fixation attacks.
Overview. The standard advice is to use a unique CSRF token that is unique for each request. Why? Because a per-request token is a bit more resilient to certain kinds of implementation errors than a per-session token. This makes per-request tokens arguably the best choice for new web application development. Also, no security auditor is going to hassle you about using a per-request CSRF token.
If you're a web application developer, this is all you need to know, and you can stop reading here. But if you're a security expert wondering about the detailed rationale behind this advice, or wondering about just how great the risk is if you do use a per-session token, read on....
Digging in a bit deeper. The truth is that, if you don't have any other vulnerabilities in your web site, a single CSRF token per session is OK. There's no reason why you necessarily have to generate a fresh CSRF token per request.
This is demonstrated by the fact that you'll also find reputable security experts who say that another reasonable way to defend against CSRF is to use cookie double-submission: in other words, you use some client-side Javascript which computes a hash of the session cookie and adds that to each POST request, treating the hash as the CSRF token. You can see that this essentially generates on-the-fly a CSRF token that is the same for the entire session.
Of course, I know the argument why some people might recommend generating a new CSRF token for every request. They are thinking, if you also have a XSS vulnerability on your website, then if you use a single CSRF token per session it will be easy to use XSS to recover the CSRF token, whereas if you generate a new CSRF token per request, it will take more work to recover the CSRF token. Personally, I don't find this a terribly compelling argument. If you have a XSS vulnerability on your site, it's still possible to recover CSRF tokens even if you generate a new CSRF token for every request, it just takes a few extra lines of malicious Javascript. Either way, if you have a XSS vulnerability on your site and you face a serious, knowledgeable attacker, it's hard to guarantee security, no matter how you generate your CSRF tokens.
Overall, it can't hurt to generate a new CSRF token for every request. And maybe it's better to do it that way, just to get security auditors off your back. But if you already have a legacy application that uses a single CSRF token for the entire session, spending the money to convert it to generate a new CSRF token for each request probably wouldn't be super-high on my priority list: I bet I could find some other uses for that money and developer energy that would improve security even more.
XSS can be used to read a CSRF token, even if it is a single submit token, that is child's play. Its likely that this recommendation of a single submit token came from someone who doesn't understand CSRF.
The only reason to use a "single submit token" is if you want to prevent the user from accidentally clicking submit twice. A good use of this is to prevent the user from clicking "checkout" twice and accidentally charging the customer twice.
A CAPTCHA or asking for the users current password can be used as an anti-csrf measure that cannot be bypassed by XSS.
I recommend reading the CSRF Prevention Cheat Sheet.