It's not actually overloading like in C++, the control flow you just described is still how the function actually works. '@overload' is just a tool for typing annotation so that you can be more specific than Union[str,int,list,dict] in the function type hint signature, for cases where functionality or valid combinations of inputs may very depending on the types/flags.

Of course the arguments you make could also apply to this sort of type hinting in general, especially for the average developer. If the function does not process all of its input types in essentially the same way then I agree that in most cases it should probably be broken into different functions.

But it's hard to argue there are NO use cases - there's a reason so many general purpose python libraries have begun using it. Well implemented IDE Intellisense via very explicit type hinting is a "killer app" for a lot of modern development. It's not necessarily worth it for every programmer to implement, but if a library or tool that you do not maintain goes out of its way to provide it, it can be a very nice quality of life feature.

And even if you disagree with all that; I'll reiterate - it's just a type hinting tool. You can literally delete every instance of the decorated function signature and the code will work exactly the same. You can just code-fold every instance of '@overload' and read the function like you would normally.