Yeah this might be true of Java, but I think for modern languages with good type inference it adds a lot to readability without much cost in terms of verbosity.
After working with more strongly typed languages, it actually seems crazy to go back to JS or Python and not have type information in function signatures. Like how are people supposed to read code and understand what this function is allowed to take?
Functional programmers also say "how can I go back to mutable state and OOP". The fact is people get stuff done in many different ways and paradigms. You found what works for you and that's good, stick to it. Others found theirs.
Before that large companies like Google got around it by annotating in the comments. It may be an inferior solution but huge codebases serving hundreds of millions of users have worked this way.
Except that very verbosity may make it easier to read, as the types themselves may supply further information to the reader about what the variable actually means.
Signatures are useful as self-documentation, and keeping them separate makes that easy to scan.
It also comes down to the compiler. If you're "annotating" your code with type "sugestions," but don't get any ironclad guarantees from it, then it's reasonable to question whether it's even worth the effort. I may be misremembering things, but "typed" versions of Python and Scheme aren't particularly rigorous.