Take a look at this haacked blog post: http://haacked.com/archive/2012/07/05/turkish-i-problem-and-why-you-should-care.aspx.
I think it answers most of your questions. Some of the pointers are:
Is it recommended to use the rules that come with fxcop?
For a new project I would enable all rules, and over time disable the ones you find distracting. For an existing project, I would enable minimal rules, and over time slowly add new rules and clean up the code as required.
The code analysis rules are:
- Design Warnings
- Globalization Warnings
- Interoperability Warnings
- Maintainability Warnings
- Mobility Warnings
- Naming Warnings
- Performance Warnings
- Portability Warnings
- Reliability Warnings
- Security Warnings
- Usage Warnings
Should it be included as a build task during builds?
Yes. This is the method I used: http://kentb.blogspot.co.nz/2011_01_01_archive.html
It can be enabled via the UI if your IDE supports it. However I had issues when different projects used different rulesets (eg, a unit test project may be more relaxed). The procedure from kentb's blog works around that issue.
Alternatively you could call FxCop directly from a post build event.
What is the value from it?
Well structured code and reduced production issues.
Are there guidelines to what rules to abide by or is it best to go with the default?
Again - go with whatever works for you. For example, you may not care that the binaries are not strongly named. The haacked blog post has some good pointers.
Is it correct to run the analysis as a post build event?
If you follow kentb's blog post, or enable it via the IDE GUI (assuming your IDE supports it), then it will be run as part of the build process. If you call FxCop directly, then it will need to be done as a post build event.