It's not a question of what one can do that the other can't. They can both achieve the same thing (they both map to CIL after all). It's usually a question of ergonomics - how much work do you want to put in to achieve the same goal. Things like algebraic data types (discriminated unions in F# speak), currying, etc. all are just a matter of making the compiler do some things that you'd do by hand in a language like C#. While you can accomplish the same thing in C#, languages like F# do it for you so you get both ease (compiler does the work) and correctness (compiler not likely to mess up where you might by hand). I bias towards the F# world for the ease and correctness reasons, but there's nothing stopping a careful programmer from achieving the same thing in the C# world.

Higher order functions, currying, discriminated unions and using pipelines to start with. I guess all concepts are technically possible in C# but the language is not really designed for it.

Express programming concepts without 12 keywords

I would add to existing replies, that recursion is probably an important part. The language needs to make it feasible to express things with recursion, by making it possible to use it for deeply recursive scenarios, without hitting language limitations. Not so many things more disappointing than not being able to properly use recursion in a language.

I've been using heavily functional c# at work with LanguageExt for about a year. It has been quite painful, especially when it comes to debugging but also because things like pattern matching are really tedious (eg. imagine a class with two Eithers, now every Match needs to handle 4 possibilities when I may actually only care about 1).

Unless f# has massive advantages over c# when it comes to functional programming, I would say this paradigm is not worth it in 90% of my programming projects.

It's awkward to do Functional Programming, when all the libraries (including the standard one) for your language built around mutation.

F# (and other FP languages, like Scala) have standard libraries which come with (and are built around) persistent collections (immutable collections, but with smart structural sharing when doing copy-on-write). And all the other libraries and the whole community is designed for Functional Programming.

There are also other aspects, that FP languages like F# or Scala tend to have shorter and prettier syntax. And many of the FP idioms are easier to express in these languages. Good example would be ADTs (algebraic data types), or Computation expressions in F# and its analogue in Scala for-comprehension. But these are more subjective reasons than my former point.

  type User = Admin | Basic

Sounds trivial but it changes everything.

More importantly is what functional languages leave out or restrict. Imperative languages can add functional language features, but functional purity is not enforced, the full benefit of functional programming is not realized.