Of course it is a good idea to enable code analysis.

But still, the code analysis can warn or give suggestions. Often the warnings are a good idea, but sometimes they are false warnings. Meaning, we should not blindly trust the code analysis like lemmings.
If working on a issue and testing it, then the analysis and warnings of this code should be fixed or evaluated by the programmer.

But we should not turn on code analysis, and then also turn on TreatWarningsAsError, which then forcues us to change all the code across all the project.

Of course it is a good idea to enable code analysis.

But still, the code analysis can warn or give suggestions. Often the warnings are a good idea, but sometimes they are false warnings. Meaning, we should not blindly trust the code analysis like lemmings. If working on a issue and testing it, then the analysis and warnings of this code should be fixed or evaluated by the programmer.

But we should not turn on code analysis, and then also turn on TreatWarningsAsError, which then forcues us to change all the code across all the project.

In general my experience with Microsoft.CodeAnalysis is that they are quite conservative, and safe to apply. If we disagree with a specific warning, or if it would introduce too much work, we can disable them (and I have already done so a few times in my PR).

You can configure the severity level of each rule separately in .editorconfig. I have set everything in the "reliability" and "performance" category to "Warning" for now, since these are important aspects of a library. For example, "ConfigureAwait" is only a suggestion by default, but as you have experienced, they can cause quite some trouble.
The other rules are still set to their default values.

If you have some time, please look at some of the changes I made with the currently activated set of rules. Please say so if disagree with some of them. I made separate commits per rule, so it is just a matter of reverting the commit and changing the severity of the rule.