In Lean Startup, Eric Ries uses extensive automated tests as an example of the different ways you can apply the ideas of lean manufacturing in software. Rob Walling, founder of the marketing startup Drip, has mentioned that having a large suite of unit tests for Drip from early on made it possible for the bootstrapped startup to move fast and refactor features as they kept learning more about their customers' needs.
As a software consultant working with multiple different projects, I have seen firsthand how test writing is often the first thing to go out of the window when deadlines start approaching and the pressure to deliver begins to grow. I'm not perplexed by this phenomenon: Tests aren't something that create direct customer value; why write a test case that users don't see if I can instead add a new feature for them? In addition, explaining the value of automated tests to non-technical people who have never had to personally experience the pain of technical debt is a considerable challenge even to the most skilful testing evangelist.
As an educator in the startup space, Rob Walling has seen an unfortunate number of software companies started by non-technical founders who have outsourced the development work and ended up with crappy codebases with no tests. After 6 or 12 months of feature development, they find themselves in a technical hole that they can't get out of without a rewrite. They might have customers but no way to build new features for them.
We tend to treat automated tests like flossing. We agree with the software experts that writing tests is an important practice, but we drop it as soon we as we are in a hurry or we just want to shave some minutes off development time. We get some short-term benefits but in the long-term we are worse off.
Since often the argument against automated tests is that we need to move faster, it's good to remind ourselves that even people like Eric Ries (one of the biggest proponents of "fast beats slow" thinking) believes in the value of automated tests. Lean Startup can be easily seen as a school of thought that encourages developers to let go of their standards for code quality and test coverage. However, automated tests enable fast learning, not hinder it: when you trust your test suite, you are able to add new features and redo existings ones without constantly worrying about breaking something else inside your product.
Teams who write tests are teams who are fast.