First and foremost, it's a design tool. Code that can't easily be unit tested is often poorly designed. The most common example in the MVC-world is a fat controller. It's hard to test any method that does too much because of all the setup that you'll have to do. If an action is doing too much, dependent on too many parts, and not very cohesive, you'll feel the pain when you try to test it.

Of course, it's just an indicator...a warning symbol. Some times method need to do a lot...sometimes they do a lot while being cohesive and not having a lot of dependencies. Ultimately, your brain is the judge, a unit test is just a tool to help measure a method's entropy.

Secondly, it's a refactoring tool. Or, put differently, it's about future correctness. Broadly speaking, in this sense, it's also documentation. At a unit test level, this is tricky...and I've struggled with it quite a bit...if you overly concern yourself with internals (using a strict mock), you'll have a brittle test which is largely focused on the current correctness. However, using loose stubs, it really can prevent the introduction of bugs without being overly brittle.