In terms of looks mostly it just doesn't have as many types and fewer parentheses. Shouldn't be an issue if you know python.
In my experience, Algebraic types alone take some work to get used to using competently. That's just one F# uniqueness and there are others. Learning Elm (a similar language) definitely made me a better engineer, but I really don't think learning F# is the same as learning Python for someone with experience with imperative/OO languages.
I think the reason it sometimes seems like it is that easy is that, as we gain experience with tools, we tend to forget the difficulties we had learning them.
I had difficulties learning OOP, I always preferred a more functional style, despite "consensus" needing 20 years to catch on that functional programming alleviates a lot of the issues we have with OOP.
Learning F# it instantly clicked.
OOP learning issues IMHO are intrinsic to the style, because it's just so seldom helpful in making programming easier.
Design patterns are just a symptom of this issue. That OOP is just a misunderstanding another.
"Real" OOP as practiced in Erlang/Elixir is quite useful.
You underestimate the importance of compatibility and familiarity for existing developers. You can show C# code to any C++, Java or even JS programmer and expect them to grasp the idea of what's going on very quickly. This is a big deal and should not be discarded lightly