The short answer is if making changes to your production environment is costly then getting changes right the first time becomes vital. If your delivering software to a client then you will build confidence with the client if you deliver 'bug free' software. If you must peform business as usual testing or as some call it regression testing then a test driven development approach may lessen this burden with time.
An equally important question is when wouldn't you use test driven development? Well when there is relatively little expense in changing the production environment and when bugs making it into the production environment don't represent a disaster. Prototyping would not require it nor would temporary applications.
Do you need nUnit to do test driven development? No, all you need is to be able to create something that will test your code, this could be a vbs script, windows app or a keyboard macro. nUnit is just a tool that takes care of the more mundane aspects of TDD. Test Driven Development is an approach not a toolset.
To me it really comes into it's own when you are constructing components/services that will be used by other developers. The tests will serve two purposes they will prove your code works (hopefully) and they will be examples on how to use your components and services.