The ...args syntax is known as a rest parameter. This allows a function/method to accept any amount of arguments as an array.

Advantages:

• From an API perspective, the logic inside the function should be able to handle any amount of arguments that will be passed in, which relieves the users of having to worry about the required argument number.
• Rest parameters can often act as sub-parameters for capturing extra (optional) data relating to function execution; such as { 'send_page_view': false } in your example.
• Because the parameters are arbitrary, a single function can exhibit functionality that parses parameters differently depending on how many were passed and what their values were in run-time. This behaviour is especially prominent in the gtag function.

Disadvantages:

• Rest parameters can sometimes lead to bad API design if not used correctly. E.g. expecting the user to pass in the correct amount of arguments in the correct order. This will first of all not play nicely with intellisense as it will not suggest where exactly should each argument be placed (because they will all be processed as a tuple) and the function designer will also need to be very careful in making sure that each argument is parsed in the correct order. All of which can be avoided by using normal arguments instead.
• Depending on how the function is used, it can arguably be more comprehensive to require an optional array instead of a rest parameter.

To reflect on gtag; it requires different parameters depending on the value of the first (command) parameter. The use of a rest parameter here is paramount as it facilitates the ability for gtag to parse and handle different combinations of arguments all in the same function. As I did mention, maintaining arguments via tuples can sometimes get out of hand, but going by the documentation - the number of arguments here is limited to 4 which keeps the cohesion for this API.