As this question mentions, a single random unguessable token per session is sufficient.
When you start generating tokens per-page or per-form, you're simply limiting the impact of a CSRF token being leaked. Singular token leakage cases are relatively rare bugs, but XSS is obviously a common vector.
In certain cases it does indeed make sense to have a per-page or per-form CSRF token, as when combined with other protection features (e.g. disabling Ajax with CSP's
connect-src directive) you can limit an XSS bug's ability to compromise CSRF tokens to the page which the XSS occurred, assuming you ensure that the token can't be re-used elsewhere.
Some people promote per-page or per-form CSRF protection as a way to increase security when using a double-submit cookie method, but I don't think this is sensible: if you have a bug that lets you read a cookie, you'd just read the session ID.
The flipside of the argument is that by implementing the more granular CSRF protection, you add additional complexity to your code, and that increases the attack surface and potential for bugs.
Personally, I'd stick with a single token per session, then implement other anti-automation controls (e.g. captcha, password re-entry) on top of this when needed for additional security.