I've worked at really small startups (<20 engineers) and pretty large companies (>1k engineers).
At small companies we have absolutely been able to get away with 0 unit tests while maintaining agility - being able to do major reactors quickly even when working in dynamic languages, while maintaining a high level of quality, even when operating at reasonably large scale. The key is clear, well written code and strong ownership from senior engineers who have a deep understanding of the code they own.
On the other hand, at large companies, extensive unit testing has been invaluable. Code bases are older, ownership changes hands frequently, new engineers join all the time, old ones move on to other projects, dozens of teams are calling each others code, refactoring is done by people who had no hand in writing the code in the first place, dependencies are higher and harder to track down completely, and it's not realistic to cover all important functionality with integration tests. Engineers often must rely on unit tests to prevent others from breaking their code, and to ensure that they are not breaking someone else's. Yes, unit tests can be highly problematic and costly to maintain, and they do add friction and time to initial development, but in these scenarios the benefits outweigh the costs considerably.
At small companies we have absolutely been able to get away with 0 unit tests while maintaining agility - being able to do major reactors quickly even when working in dynamic languages, while maintaining a high level of quality, even when operating at reasonably large scale. The key is clear, well written code and strong ownership from senior engineers who have a deep understanding of the code they own. On the other hand, at large companies, extensive unit testing has been invaluable. Code bases are older, ownership changes hands frequently, new engineers join all the time, old ones move on to other projects, dozens of teams are calling each others code, refactoring is done by people who had no hand in writing the code in the first place, dependencies are higher and harder to track down completely, and it's not realistic to cover all important functionality with integration tests. Engineers often must rely on unit tests to prevent others from breaking their code, and to ensure that they are not breaking someone else's. Yes, unit tests can be highly problematic and costly to maintain, and they do add friction and time to initial development, but in these scenarios the benefits outweigh the costs considerably.