> in just about every sane language (not to mention plain-old mathematics), extraneous parentheses don't behave like this.

Let's test that out.

Python 3 doesn't like extra parentheses:

    a = ['hello', 'world']
    print(*a)    # OK
    print((*a))  # ERROR

Ruby doesn't like extra parentheses:

    a = ['hello', 'world']
    puts(*a)    # OK
    puts((*a))  # ERROR

C++ doesn't have a splat for C-style varargs functions but it does have one for template parameter packs and it doesn't like extra parentheses:

    template <typename ...Args>
    void g(Args... x) {
        f(x...);    // OK
        f((x...));  // ERROR
    }

Go doesn't like extra parentheses:

    package main
    import "fmt"
    func main() {
        a := []interface{}{"hello", "world"}
        fmt.Println(a...)    // OK
        fmt.Println((a...))  // ERROR
    }

Lua doesn't like extra parentheses:

    a = {"hello", "world"};
    print(table.unpack(a));    -- OK
    print((table.unpack(a)));  -- Only prints "hello"

Perl does like extra parentheses (but then again it doesn't really have a special "splat" syntax and just flattens all lists everywhere):

    my @a = ("hello", "world");
    print(@a);    # OK
    print((@a));  # OK

You seem to want `...` to behave as an operator, but it really can't since it doesn't produce a value. If you think it *should* produce a value you then have to decide what the type of that value should be and there doesn't seem to be a good answer for that. I mean, should this be allowed?

    let a = ['hello', 'world'];
    let b = (...a);  // What should the type of `b` be?

    // Somehow equivalent to console.log('hello', 'world')?
    console.log(b);

I suppose you could introduce some MagicFlattening type into the language and make `b` be of that type. Then every time any function is called the interpreter would have to check and see if the argument is a MagicFlattening object and, if so, change the call from having 1 argument to having N arguments. This would make things slower and make creating a JIT more difficult. It would have unfortunate ripple effects across the entire language. You've now got these magic objects floating around that can unexpectedly change the meaning of any function call in your program. This is probably why most languages have chosen not to go this route.

Instead `...` is a different way of calling a function. You can call a function in the normal way with `(` and `)` and you call it in this alternate way with `(`, `...`, and `)`. Any given call site only uses one or the other of these ways and which one it uses is known at compile time so there's no need for runtime checks and no magic objects.

The `...` is part of the function call so wrapping it in extra parentheses doesn't really make sense. You wouldn't change `console.log(a, b)` to `console.log((a, b))` and expect it to work the same, would you?