That’s a very good question. I very much appreciate your interest in this and will try to explain as well as I can. Hopefully other people familiar with F# can join in.
In general, I think it’s not as easy to talk about complexity of a syntax. It has a voodoo magic human psychology aspect to it. Number of keywords or rules is precise, scientific and quantifiable. But I suspect it doesn’t entirely capture how the code looks (and is perceived) when printed on screen.
Here are the main reasons why I think some people might prefer F#'s syntax over Scala’s.
Significant white space
F# uses new lines and indentation for blocks.
let simplePatternMatch =
let x = "a"
match x with
| "a" -> printfn "x is a"
| "b" -> printfn "x is b"
| _ -> printfn "x is something else"
In Scala 2.x you have to use a lot of { and }.
val simplePatternMatch = {
val x = "a"
x match {
case "a" => println("x is a")
case "b" => println("x is b")
case _ => println("x is something else")
}
}
Scala 3 is changing that, so we’ll see how it will fare in practice 
Quiet function application and pipelining
In F# you apply a function to an argument just by putting them next to the other. A legacy of ML, I presume, because Haskell has it too. Another popular way is to use the pipe operator which works on any function – great for modularity.
f x
g (f x)
x |> f |> g
x |> f |> g |> h |> i
In Scala you have to use ( and ) everything. Since |> isn’t in Predef, people would have to (create it or) import it, so they don’t do that. Instead, they rely on method call chaining for similar effect, which is nice, as long as you use the members available on the object. When not, you’d either have to create an extension method, but that’s not worth it for just one or two use cases, so people resort to ( and ).
f(x)
g(f(x))
f(x).g
h(f(x).g).i
Function composition
Since in F#, “everything is a function”, you can use >> to compose two of them.
f >> g
I remember that in Scala I sometimes had trouble with composing functions (>>>?), because not all the things were functions, some were just members/methods and so I had to resort to creating a lambda verbosely instead of the desired f >>> g. But I have trouble finding a specific example, so this is me speculating here.
{ x => g(f(x)) }
f >>> g // sometimes didn't work for me? idk
Perhaps some people more knowledgeable about this could tell us if Dotty improves this.
Currying
Functions are curried by default in F#, that makes their definitions more uniform.
let f x y = ...
In Scala you have to make decisions on how many blocks you want to have and what goes into each.
def f(x, y) = ...
// or
def f(x)(y) = ...
Value declaration
F# has only let, for both functions and “normal values”. There’s also the mutable qualifier, but that is discouraged. It uses module for module declaration (but they’re not worked with as normal values, unlike in Scala).
let name = "hello"
let double x = x + x
let mutable num = 5
module M =
let x = 3
Scala has val, var (discouraged), def, object and val can also have the lazy qualifier. The distinction between zero argument def f = ??? and val f = ??? might feel subtle to some people.
val name = "hello"
def double(x: Int) = x + x
var num = 5
object M {
val x = 3
}
I could see why somebody might feel F# is simpler in this regard. (But it has to be said that it has easier time achieving that because it doesn’t have all the functionality Scala does.)
Type declaration
F# has only the type keyword for ADTs, records, type aliases, classes, interfaces. For abstract classes, it uses the [<AbstractClass>] annotation.
type Tree<'a> =
| E
| T of l: Tree<'a> * v: 'a * r: Tree<'a>
type Person = { First: string; Last: string }
type Transform<'a> = 'a -> 'a
type Product (code:string, price:float) =
let isFree = price = 0.0
member this.Tag(currency: string) = sprintf "%s: %f %s" code price currency
type IPrintable =
abstract member Print : unit -> unit
Scala has class (optionally with abstract or case modifier), trait, sealed modifier and type for type aliases/members.
sealed trait Tree[A] extends Product with Serializable
case object E extends Tree[Nothing]
case class T[A](l: Tree[A], v: A, r: Tree[A]) extends Tree[A]
case class Person(first: String, last: String)
type Transform[A] = A => A
class Product(code: String, price: Float) {
val isFree = price == 0.0
def tag(currency: String) = s"$code: $price $currency"
}
trait Printable {
def print(): Unit
}
(Scala 3 is fixing the ADT situation 
)
For both let and type, it’s always followed by = and a possibly newline and indentation. No with, :, .., where or anything like that. In a different world, I could imagine Scala adopting something like that
class Product(code: String, price: Float) =
val isFree = price == 0.0
def tag(currency: String) = s"$code: $price $currency"
In F#, it’s noteworthy that since the keyword is (almost) always just type, the meaning of it is determined by what follows after the =. This is analogous to how let works.
Code is not cyclic, has to be sequential
This isn’t at all related to syntax, but it’s an awesome, sometimes under-appreciated feature of F# that I sorely miss in Scala.
Modules and the code in modules can’t be cyclic, the compiler requires that it is sequential, from top to bottom, code files processed linearly from one to the other. There are escape hatches, because there are legitimate reasons to break these rules, but because the enforced default is no cycles, it leads to more clean and readable F# codebases.
module A =
let double x = x + x
let f x = double x + 42
module B =
let triple x = A.double x + x
Where as in Scala you can write
object B {
def triple(x: Int) = A.double(x) + x
}
object A {
def f(x: Int) = double(x) + 42
def double(x: Int) = x + x
}
Avoiding cycles is a great way to simplicity.
There’s an interesting story to F#'s syntax. A bit over 10 years ago, it underwent a similar, also elaborate, simplification and white-spacification as Scala is undergoing now. It started with “verbose” syntax, but transitioned to the “light” syntax which requires less keywords.
More on that story in the article The Early History of F#, chapter 9.10 F# 1.0 - Improving the Functional Core: Indentation-Aware Syntax (on page 36) and the blog post it links to.
Btw, with your example [1;2;3;4] vs List(1, 2, 3, 4) I agree, after getting used to it, I now prefer it the List(...) way. If only I had to be a devils advocate and tried to find reasons why is [...] better, I’d say that List could possibly be any method or object with apply method, depending on your imports and so you have to be paranoid, while with [...] you can always be sure that it’s just a list and nothing else.
For the record, I’m not just some Scala hater. Here I’m appreciating Scala’s strengths in another forum. I’m very grateful that you Martin (and all the people who helped you) started working on Scala all those years ago, so that I today could write Scala, have fun and get paid for it. 
Keep up the awesome work!
