Disclosure: I
didn't like the talk.
In Uncle Bob's view, which I assume has some popularity, unit-tests are a form of software specification. It's informal as the specification can only test specific examples of behavior based on a determined state and the people responsible for its maintenance are the programmers. And if you're not disciplined enough with how you write these tests you end up in a situation where you're writing the rules for your own success and the specification itself contains errors.
I look at specifications as blueprints. If you're planning a sky-scraper or mass transit system you use blueprints. If you're building a shed in your backyard you might just use a quick sketch on a napkin. I think the majority of commercial software is somewhere between napkin and blueprint; building houses to lean on a well-trod analogy.
You need something more specific and robust than a sketch on a napkin but not quite as formal as a blueprint for a rail switching system.
Regardless unit tests are not a very good specification format. They're only going to show you examples where your software meets your requirements. However we all know that software is complex, hard, and systems are more than the sum of their unit test suites: there are operators involved, conditions and constraints on its operation, failure modes. You need a tool to help you design the system and check your work for you because these systems are getting too complex for you to reason about without solid abstractions.
I think Rich Hickey completely missed all of this when he said that in his talk. If we were to modify the analogy to fit the view of testing as described the guardrails would have holes in them. All over the place. You'd only be safe in the cases where the car "bumps" into the correct spots you thought to put a test.
However I do agree that unit tests alone cannot be relied upon as the only way to write "correct" software where "correctness" is determined by it's adherance to its specification and that the implementation of it follows state of the art practices. One has to do more than just use unit tests to achieve that.