I find that immutability often makes it easier to reason about non-concurrent code as well. For instance, if I've got a mutable field in a class which is read in some method, then as a code reviewer I might have to inspect every other method in the class to see how it could have received its current value. If it's an immutable field, then I know that it has the value that it was assigned in the constructor.

That's not to say that immutability is always better, of course, but I think it's a sensible default even before considering any implications for parallelism/concurrency.

Immutability makes it easier for the human programmer to author correct concurrent programs.

There is no easy way to tell if a function is pure (has no effects) in .NET. For example

let f x y =
let a = g(x)
let b = h(y)
System.Math.Min(a,b)

is 'f' pure? Well, it is, provided that 'g' is pure, and 'h' is pure, and System.Math.Min is pure. But these functions may reside in other assemblies, or require their own analysis. There is work to provide that kind of analysis and metadata information, but I think it's still in the 'research' stages.

And even if you knew this was all pure, then will running g(x) and h(y) in parallel make your program faster? Well, if each of those functions takes 10 seconds, then almost surely yes. But if they are tiny functions that will execute in under a millisecond, then it will be faster to just run them in series than to run them in parallel and deal with the fork-join overheads. So figuring out 'granularity' is a hard problem too, even after you have the purity/effects problem solved.

Overall, I am betting it will be at least 20 more years before there is any industrial strength tools that can reliably auto-parallelize code in general cases. There are still many hard problems to be solved.

The good news is that human programmers will continue to be in demand. :) At least using F# will help make your concurrent programs much easier to reason about!