Using POST offers the following advantages over GET:
Avoid the browser's URL history. Any sensitive data in the form is not passed in the URL, which means that data in the form are not visible in the browser history and cannot be shoulder surfed once submitted. (Note: the form body is sometimes stored, depending on browser and settings, but is usually not visible).
Ability to pass hidden tokens. Using POST gives your application the flexibility to include more fields (there is a hard limit on the length of a GET request), including such important things as CSRF tokens, ViewState MAC checksums, etc. You would not want to show these fields in the address bar.
Less Logging. Data in the URL itself is held in an HTTP header, which is more likely to be logged by intermediate network appliances (e.g. if using SSL offloading or deep packet inspection), or by web server logs. IIS, for example, logs the entire URL and querystring with each and every request, by default, and this gets stored in a flat file which sits on your web server forever. Data in the form body, on the other hand, is not logged by default.
Avoid sending PII to analytics. If there is sensitive information in the URL, you risk that data ending up being sent to any analytics solutions or third parties you are using. Generally speaking, data in the form body isn't going to end up getting sent unless you went out of your way to code for it.
Does using POST automatically mitigate the risk of CSRF? NO!! But typically a CSRF mitigation will involve using HTTP POST + an anti-CSRF token, so I could see why you'd think these go together. Without the token, the POST verb does nothing in and of itself to mitigate CSRF via reflected or stored XSS.