Clean Code, e quaisquer outras "boas práticas", não são leis sagradas, e nem regras universais. São no máximo recomendações, sugestões. Você analisa, vê os prós e contras e usa quando fizer sentido (como tudo em computação, aliás).

O caso do vídeo é um exemplo de quando não usar. Se vc precisa otimizar ao máximo, e pra isso precisa quebrar algumas regras, vá em frente. Não vejo problema nenhum em ir contra o "senso comum", se for algo bem justificado. Desde que, claro, sejam justificativas técnicas, e não dogmáticas ou ideológicas (ou então por moda, "todo mundo faz", e a famigerada desculpa-mãe de todas, "é boa prática").

Mas tem casos em que justifica sim. Um código que não precisa de otimização extrema, que nunca roda com muitos dados, e no qual a diferença entre 1 milissegundo e 50 milissegundos não tem impacto nenhum, seria um em que eu poderia seguir o Clean Code. Eu não tenho dados oficiais, apenas experiência pessoal (e portanto é mais anedótico do que factual) de que seguir alguns princípios, especialmente em equipes que mantém bases de código grandes, pode ajudar na manutenção. Não quer dizer que se seguir tudo à risca, nunca terá problemas. Mas ele pode ajudar sim.

Mas como eu já disse, cada caso é um caso. Em código throw away (aquele "scriptzinho" que só vai rodar uma vez) eu não me preocuparia com nenhuma "boa prática", e dependendo do caso nem com performance. Em projetos de longo prazo, melhor manter um mínimo de organização, e isso pode ou não usar um ou mais princípios desta ou daquela metodologia. E se precisar quebrar alguma regra, desde que bem justificado, não vejo problema algum. Contexto é tudo.

O problema de qualquer coisa em computação não é usar, e sim usar errado (quando não é adequado ao problema/contexto, ou quando o uso excessivo acaba tendo o efeito contrário do proposto).