You’re a little confused about terminology and what factors are relevant, as people mentioned in the comments. Let me just address the syntax of Erlang, which is a functional language.

It has more operators because it does more. It needs a ++ because it was already using + for something else. It uses ++ instead of a word like concat because the language was intended to favor conciseness. For example, the code:

[Front || Front <- Rest, Front < Pivot]

Requires the following code in C++ (copied from here):

int partition(int* input, int p, int r)
{
    int pivot = input[r];

    while ( p < r )
    {
        while ( input[p] < pivot )
            p++;

        while ( input[r] > pivot )
            r--;

        if ( input[p] == input[r] )
            p++;
        else if ( p < r )
        {
            int tmp = input[p];
            input[p] = input[r];
            input[r] = tmp;
        }
    }

    return r;
}

Although the same code in python using list comprehensions is just barely longer:

[front for front in rest if front < pivot]

Because of immutability and lack of side effects in functional programming, certain methods of processing lists have been adopted which make it easier. This includes pattern matching and destructuring. You might want to do some research on those, but my point is in order to gain the expressiveness and conciseness that things like pattern matching provide, you have to accept more complexity in your syntax.

Also keep in mind that C++ and python seem more natural largely because you learned them first. If you had learned erlang first, then C++ and python’s syntax would seem limiting and excessively verbose.

It sounds like your observations about syntax are merely preferences, so let me make some observations of my own.

First of all, let me state equivocally that syntax does matter. The simplest syntax of all is Lisp:

(defun fib (n)
  (if (< n 2)
    n
    (+ (fib (- n 1)) (fib (- n 2)))))

Because code is essentially data in Lisp, lisp can understand code written in lisp, which makes writing a parser for Lisp in Lisp (or in any other language, for that matter) an almost trivial exercise. Lisp is widely regarded as a language where problems can be solved from the ground-up, in problem domains that would ordinarily be resistant to coding solutions (especially in domains where requirements are constantly changing). Lisp is a very expressive language, and at the end of the day, syntax is the way we express ourselves in a language. It is not, however, regarded as the most readable of languages (all those parentheses).

Programmers typically fall into one of two camps, syntax-wise: those that prefer a more English-like code representation, and those that prefer a more symbolic, mathematic-style code representation. The syntax of the language itself will be shaped, in large part, by the goals of the language.

For example, C is basically a high-level assembly language. It uses the syntax that it does, in large part, because it maps well to underlying assembly instructions. It has no need for lofty concepts like natural-language translation, preferring to map closer to the metal. Many languages that came after C adopted the brace structure and other syntax idiosyncracies because C had already done it. C is in the “symbolic” camp.

unsigned int fib_rec(unsigned int n) {
    if (n == 0) {
        return 0;
    } 
    if (n == 1) {
        return 1;
    }
    return fib_rec(n - 1) + fib_rec(n - 2);
}

Some languages, however, like Python, prefer to work at higher levels of abstraction and seek to be closer to the language used by humans. These languages will prefer things like significant whitespace, because it produces less clutter between the words than braces. Python is in the “English-like” camp.

def F(n):
    if n == 0: return 0
    elif n == 1: return 1
    else: return F(n-1)+F(n-2)

I was a Visual Basic programmer for years, and so was in the English-like camp, until I learned C#. I now prefer the better precision and less ambiguity that C# offers; I think in terms of what I need the computer to do, and C# seems to maps more closely to that. I like the fact that you can line up blocks of code in braces. I like that certain things are expressed more succinctly in C#. But the capabilities of VB.NET and C# are nearly identical, so the choice between those two languages really does come down to personal preference.