Let me give a real-world example of the business case.
Over the years I have seen many articles, perhaps even up to the hundreds, that tout the number as approximately 1:1 when it comes to comprehensive automated testing and green development. Since we track our progress carefully, I can agree with those numbers in my personal experience. It takes about twice as long to write code+tests as it does to just write code without tests.
We have a game engine that has been in use since 2005. This engine has many hundred thousand unit tests in it. The physics library has unit test, the pathfinding has unit tests, the spatial systems have unit tests, the animation components have unit tests, and so on. If someone were to introduce a significant bug in the system it could take down not just the one developer, but potentially take down the entire team for several days. Such critical bugs do sometimes get introduced, and by the time you factor in just a single day of lost productivity among all people on all teams the cost of such a bug can reach around 150 work-days lost. This is exactly the type of scenario the video is talking about. For this type of engine, a long-term project shared by many people, or a project in long-term maintenance, there is a compelling reason to write the tests.
Now let's look at the other side, the people who use the engine.
Developing a new item with this engine requires about 3 weeks of development time followed by about 2 weeks of QA time. Programmer hours are expensive, QA hours are cheap. When a new item is developed it is launched, gets put out the door, and is generally never touched again. The code is effectively thrown away. Of course it is not completely thrown out, we routinely pull code from prior items and reuse them, and some of it gets incorporated back to the engine where tests are developed for it. Now over the course of several years and several hundred items we have only had three items where customers found significant bugs that required a re-release. The cost of these bugs is practically zero, and unit tests would not have helped avoid them. The cost to do a single QA push is far less than the additional cost of writing the automated tests. The automated tests have no lasting value because the code itself has no lasting value.
I am a strong proponent of TDD when it makes sense. I love it. The red-green-refactor mantra plays in my head even when I writing throw-away script code because in practice I still follow it: I have a thing to change, I make the change, I test the change, I clean up, I retest, and I submit the code. However, I am an opponent of TDD when it does not make sense. It does not make sense in code which has no long-term value.