I love type inference, but I feel like using it in this way doesn't realize its full potential. My functional background primarily stems from SML (and some Clojure), but the logic I'll use should apply here as well. It's true that the compiler is able to infer the most general type itself, but if you rely on it for this you're ignoring an invaluable tool for predicting the correctness of your code.

There are many times where I've used type inference to show me there's an issue with my code before I even run a single unit-test. I always specify the types of my arguments as well as the return type when writing a function, even though it's not technically required at this point. If I've fully reasoned through what it needs to do then this shouldn't be too difficult. Once I've finished I'll make sure it type-checks. If it does then I'll know the logic throughout my function matches the inputs and outputs I've specified.

That gives you a powerful low-pass filter for knowing whether or not your code is more likely to be correct. If you specify the types when you declare the function and they don't match then your code won't type-check, which results in an exception. If you don't, then depending on the type of error your function might still type-check and compile, but with the wrong type. Then you have no choice but to catch the error with unit tests or, even worse, debugging. The interpreter will certainly give you the type for the code that you've entered, but assuming that it's giving you the type for the code you actually need leaves a powerful tool on the table.

Obviously this doesn't cover every class of error you could have in your code of course, but it in my experience it can be very helpful.