Just for me (YMMV) I find that when I write untested code, I make too many large cognitive leaps in my changes. My code looks good at the time and it usually looks well-factored, but entropy and shortcuts always seem to creep in there. Pile all those errors up over a 5 year timespan on code that slowly accretes since I'm maintaining it on my leisure time, and I always wind up with really untrustworthy code and occasional frustrating regressions when I make changes.
The test suite with good coverage gives me confidence that the code continues to work as I make changes (no regression bugs.) It's about having complete trust in my code, no second guessing, and no time ever wasted in a debugger chasing down issues.
And, I want to be able to cut a build at any time as long as all of my tests pass and feel confident I'm not shipping a broken build. I've never been able to do that on any project in the past, and I think it will be one mark of success on this new project. I've implemented a mini feature toggle system in my build scripts to make that possible.
Finally, I'm using Closure Compiler with full optimizations in my production build to do minification. Closure Compiler itself can (theoretically) break the build with its over-aggressive optimizations, so part of having a complete coverage test suite is being able to run the tests against the production build and catch any bad optimizations that CC makes. Because of my architectural choices, I REALLY need that test suite.
Do I need to write the tests before the production code (do full TDD) or can I write tests after? Well, I am the type of guy who won't write the tests after because I always want to move on to the next fun thing. I just force myself to do it, and take my medicine up front.