It's an implementation of "ad-hoc polymorphism", where, for example, it may make sense to "add" (+) together numbers of various types: integers, floating points, rational numbers, etc.

Thus the (+) operator for addition is "overridden" or "polymorphic" in the types of numbers that can be added together.

The argument for having a polymorphic signature rather than just multiple separate "monomorphic" functions is similar to that for "generics," otherwise known as "parametric polymorphism": why not just have a function `forEachInt` for iterating over lists of ints, a separate function `forEachChar` for iterating over lists of characters, and so on?

Higher levels of abstraction and generality, less boilerplate and coupling to any particular choice of data structure or implementation.

You could of course go the route of golang which indeed just had you write "monomorphized" versions of everything. Several years later generics were added to the language.

Alternatively, you throw everything out and never have to worry about typing or polymorphism, at the cost of static safety.

I would recommend reading the article example once more. Going from the example, without the overload, the function would return a union type which means any time you use the function, you have to put a type check to the result to know if the output is a list or not. With overload, as soon as an argument to the function is a certain type, the output is determined, so you won't need to type check.

I think that GP's point is that you could accomplish the same thing by simply having separate functions with different names, signatures, and return types.

In other languages it's an alternate way to do default or optional values in function arguments. Python instead usually uses kwargs for this.

That's what you get when you add a typing system and come full circle to doing OOP like Java.