The biggest benefit I've been seeing from unit tests is in writing more of them inside a code base sorely lacking them. In that case there's a big side-effect of making the underlying code unit-testable (that is, if you don't totally cheat every time with something like PowerMock). Some tests may get blown away in refactoring, but testing the new code has the same benefit. In many cases this makes the implementation uglier but doesn't hurt its clarity much (oftentimes it can improve it), especially with IDE assistance.

Building up small oases of dumber/more verbose code that has unit tests seems like the best way to wrangle legacy code into something that anyone else on the team can understand and not mess up 6 months from now when it's their turn to have to touch it for the first time. Of course no one wants to touch that 200-line, 10-levels-of-indentation monster method, but bringing just a little bit more and more of it under unit test over time will help a lot. Every other benefit of unit testing that you listed besides the time saving aspect (e.g. why launch a big e2e test if you can test the same thing in an xunit-like context? even if it's not strictly a "unit" test) pales in comparison of the benefit of making crap code nicer to work with. A corollary is that if your code is already nice to work with, and you have a system to keep it that way, unit tests won't be very valuable. (Though other tests, which may or may not be in an xunit-like context, may still be quite valuable.)