Since you're "coming from the Python world" you have a good case-study in how a bunch of things outside of language design are crucial. Python has essentially won the race to be the next major language among scientists and that's tied up with a virtuous circle of libraries for, e.g., numerics, statistics, data viz, machine learning, and even within many scientific disciplines (e.g., astronomy). The virtuous circle also includes learning resources (books, Websites, conferences) and the ability to have someone check / talk over your code.
For what it's worth, F# is trying to get that same virtuous circle rolling, but there are a few areas (cross-platform dataviz, interactive notebooks) where F# just doesn't have quite as good a story as Python.
Yes, functional composition in part. And while pretty-much-everyone has first-class functions now, they're usually not _quite_ as easy to declare and use as they are in F# (e.g., if you have to specify `Func<string, Func<string, int>> Foo` rather than `let Foo s1 s2 = ... `
Another data-wrangling thing easier in F# (not FP in general) is type-providers.
I'm no believer in silver bullets, but I wonder about "the productivity difference is only marginal." For one thing, I think being an F# dev is likely to improve one's OOP code (immutability by default, smaller methods), so while I agree that it might feel like one is similarly productive, I think one changes one's baseline.
For another, I think it really boils down to maintainability. Elsewhere in this thread, there is a comment that "return to your code in 6 months and it's incomprehensible." As a guy who worked with a large Scala codebase, I totally "get" that, but the thing with "functional code you haven't seen in 6 months" is: It's either incomprehensible or it's MUCH easier to reason about than stateful OOP code. And the "incomprehensible" stuff tends to fall into a couple different categories (lifting and conversion, complex function composition, etc.) that gets at least a _little_ better once you've hit your head against them a few times.
I prefer F# as my day-to-day, but I can understand why, for day-to-day challenges, a lot of devs might look at some language features and say "C# has something that's pretty similar." However, use-cases that can be solved elegantly by pattern-matching, type providers, and/or computation expressions are areas where the "C# is good enough" argument is harder to make.
One set of use-cases where pattern-matching are particularly valuable is parsing and other times when you're deconstructing / transforming a complex structure.
One use-case for a type provider would be, say, taking an XML schema and exposing its structure as a compile-time constraint.
One set of use-cases where computation expressions are valuable relate to (oh god I don't want to use the "M"-word) the creation of a small DSL that isolates some type of specialized computation on a parameterized type. For instance, the (built-in) `async` computation expression.
Those might sound like fairly esoteric use-cases, but they're really not that uncommon if you do DSL / library development.
Actually it wasn't as revelatory as you might think.
Windows programming was irrelevant in the 80s -- it wasn't until Windows 3 and 3.1 that it really caught on. In the DOS world there were lots of "character-mode windowing libraries" (I mean lots : I think we once reviewed 15 in a single issue of Computer Language) and they all generally had fairly straightforward programming models. People were much more focused on, for instance, memory management.
When NeXTSTEP came out, word traveled by the magazines and BBSes and Compuserve fora. You couldn't really communicate the NeXTSTEP programming model in pictures and so the only people who I think really got NeXTSTEP were people who'd already experienced Smalltalk! (Which, at the time, was at it's peak, with Smalltalk/V available on DOS machines and ParcPlace available on UNIX systems.)
EDIT: Go is intended to be a systems-programming language with an emphasis not only on runtime efficiency and concurrency, but additionally on such things as compilation speed.
Scala is intended to be a hybrid OO-functional language that is approachable by a broad class of mainstream programmers (i.e., Java programmers), with a type system considerably more sophisticated than Java. The emphasis is, I'd say, on a language that has long-term potential, at the cost of a somewhat problematic toolchain.
JavaScript's enormous advantages are that it is universally available, easy to approach, and flexible enough to support functional techniques.
For what it's worth, F# is trying to get that same virtuous circle rolling, but there are a few areas (cross-platform dataviz, interactive notebooks) where F# just doesn't have quite as good a story as Python.