Lisp syntax is not required for this. There is no reason that you could not write:

    (if (condition) '+ '*) (2 3)

and have that mean a conditional function call on the arguments 2 and 3. In fact, many traditional-syntax languages allow you to do that, e.g.:

    Python 3.8.9 (default, Mar 30 2022, 13:51:16) 
    >>> def f(x): return x+1
    ... 
    >>> def g(x): return x+2
    ... 
    >>> (f if 1 else g)(4)
    5

No, the real reason you want (f x y) rather than f(x y) is so you can parse it with no lookahead.

It is actually possible to extend Lisp's syntax to allow f(x y) using the hack that if there is no whitespace between a symbol and an open-paren then treat that like a function call, i.e. you can tweak the Lisp parser so that:

    (list f(x y) f (x y))

will read as

    (list (f x y) f (x y))

and so kinda sorta do the Right Thing if you like traditional function call syntax. But that is pretty hacky and fragile.

Even with lookahead, it seems like there are ambiguous cases. I think the "hacky and fragile" level is so high, that it rises to a level of "practically required" to avoid ambiguity. (In the sense of "if John McCarthy had proposed it the other way in an early draft, it would have been peer reviewed out before the first implementation.")

In a sequence of expressions, how would I [or the computer] know how to evaluate the following

  g (a b) h (c d)

If g (a b) returns a function f and h (c d) returns a value v, should the result of that evaluation be v or f(v)?

Does our intuition change if I write it as:

  g (a b) 
  h (c d)

If the default is for the result to be v, and I do want it to be f(v), it's not obvious to me how to re-write it, whereas it's obvious if the first element in a list is a function call:

  (g (a b))  ; ==> f
  (h (c d))  ; ==> v

vs

  ((g (a b)) (h (c d)))   ; ==> (f (v))