The only right answer is: "Maybe, it depends on the context"

Everything said from here on could be applied to Clean Architecture as well, although it is a diferent topic from Clean Code.

Clean Code (or Architecture) main purpose is to mantain productivity sustainable through time by keeping complexity and costs under control. It's a well known topic with many papers and researches made around it.

It shares many things with TDD, Domain-Driven Desing, Agile, etc. None of those are meant to speed, instead they are meant to stability and control dealing with complex environments.

I'm not triying to advocate in their favor by any means, for sure they has some flaws by their own. But those tools won't make you build a product faster or produce fast applications by themselfs alone. Although is not the main goal, eventually an increase of speed could be an outcome of using them.

The real problem is the dogmatic approach many take, on both sides agree or disagree, about a particular practice, methodology or tool. You've to know why and when to apply it or if it's really beneficial in your particular case.

Clean Code practices are really useful for some contexts of software development but may not be suitable in other cases, although exceptions are the least.

Different problems requires different solutions, there is no silver bullet.

It is an interesting topic, but the original video that started all this debate is basically misleading.

The author cherry-picked just a few of the points from Clean Code book to invalidate the whole concept and completetly ignores the rest in order to focus on the points that confirms his conclutions.

The video applies a Game Development perspective, with small teams or lone developer, to every single development. That perspective could not be valid on a heavily bussiness based development enviroment, large legacy codebases, medium to large team size or high staff rotation.

Furthermore, he refers to the performance penalty on the magnitude of CPU cycles. That kind of low-level optimizations may be useful in Game Development, but it is not needed for most of software development contexts and the costs to invest on it is would not worth it on many cases.

It's a fact most of the software developments are not system software or games with special needs concerning to prioritize performance above all.

In conclusion, any tool to help the development proccess of a software solution is subdue to a concrete context. In some cases you may find it useful, in other cases you can use some of the points but not others, or none of them at all.

Defending any mindset as a dogma is never the right way, you have to know the purpose underneath and when to use it. And at the same level, completely deny an concept just because some aspect of it may not fit into your particular case is a lost opportunity.