1) I like to write a 'nominal case' unit test because it helps me think about the sort of API that I want, and it let's me see the fun stuff up on the screen very quickly.
2) I've found a bug, so I write a unit test because apparently this bug was in code that I wasn't able to reason about correctly when I first wrote it, which means it is probably tricky - the unit test will stop regression.
3) When investigating a bug, and I want to assure myself that a subsystem is reacting the way that I expect it to, I sometimes write unit tests as a way of proving to myself that I have understood what is going on.
I've seen other people write loads of unit tests for every single little thing, but it actually makes their code more rigid, as if you want to change an interface, you not only have to change the code in the product, but you have to change all of the unit tests too. The result is that people don't like changing what is written, and prefer to overlay a level of abstraction to avoid the rewrite, leading to less clear architecture overall.
As you mention, unit tests work well for algorithmic stuff.
Thing is, in most of what I do every day, what I care about is the end result. It doesn't matter so much to me that calling a specific function with a specific set of parameters produces a specific result, what I'm more interested in is sending a signal into the application and getting an expected output somewhere down the line.
Of course when I'm working on something more algorithmical, unit tests are preferred and tend to produce much better results. But this kind of work is unfortunately quite rare.