This is turning into an argument for strong typing, but, in light of your original claims, only for external inputs, not for internal interfaces - but if it is useful in the former case, why not the latter?
In some cases, say when you work very close to a business domain, this may very well be a good thing. But for larger applications, especially that do low-level stuff, the tradeoff is cluttering your namespace with single use parameters. You quickly run into scaling problems.
It's exactly the same reason bindly following "textbook" OOP design is a bad idea. Unless you're able to do some very prescient upfront design of a large part of your application, you're in for a big headache later.
I mean that you need to assign each type a distinct name, and in many programming languages, the namespace for types is effectively global.
If you add say a thousand types for all the things combinations of things you may want to represent, then you've effectively added the need to have a thousand type names.
That is merely being explicit about what is implicit otherwise. When you are being explicit, there is at least the possibility that these declarations could be scoped - and, in many languages, this is something you can do.
