I'd argue a variable number of arguments is a less problematic form of overloading since it's much easier to see the difference between f(a, b, c) and f() than it is between f(a, b, c) and f(x, y, z) (which can only differ in argument types).
Plus, we already have a bunch of functions that would be really nice to have them become variadic, e.g. min/max and iter::chain/zip.
Another use case I have that isn't nearly as compelling of a use case is that I have a library that is manipulating types at runtime for a domain-specifc language embedded in Rust and it needs some syntax for a runtime equivalent of supplying generic arguments such as T, U, and V for a generic type MyStruct, like the Rust syntax MyStruct<T, U, V>, to generate a runtime type. Currently I'm using the Rust expression MyStruct[T][U][V] since that allows a variable number of generic arguments to be supplied which is needed for handling defaults (e.g. if V is omitted, it could use the default type for that generic parameter instead). It would be waay nicer to be able to write MyStruct(T, U, V) since that returns by value and doesn't need a bunch of intermediate types with Index impls and doesn't need a final step to fill in default values.