Sim, coloco em prática tudo o que aprendi em produção e desde então, me facilitou demais problemas com bugs e manutenção, principalmente porque vários dos problemas críticos que podem acontecer na aplicação estão garantidos pelos testes. A ideia de mudar o banco é meramente ilustrativa, e me serviu de exemplo pra dar o tom do que é mais importante na aplicação, em um projeto que começa do zero. Ou você vai me dizer que o principal é o banco e o código, e negócio, é secundário?

É claro, que raramente se precisa mudar. O ponto todo é que não tem porquê, de forma alguma, acoplar o banco a troco de nada, a troco de não usar um simples pattern de repository ou adapter na aplicação, que implicaria em uma arquivo de interface e uma injeção de dependência, onde em uma tarefa rotineira, não implica em muito mais trabalho e não diminui em nada a performance... não que você ou alguém em experiência de uso notaria. Eu olho pra um projeto "clean code" e sei onde as coisas estão, pode haver diferenças aqui e ali, mas mesmo essas mudanças são padrões. Se levarmos o princípio da menor surpresa em consideração, o que parece complexo pra quem não conhece, se torna muito comum e fácil de entender pra quem conhece. O complicado mesmo é o "simples" que pode ser feito de muitas maneiras diferente, e como ninguém segue padrão nenhum, cada um faz do seu próprio jeito.

Nos outros casos, na gisgantesca maioria das vezes, é como você falou, claro que ninguém precisa usar microserviços. Isso é uma coisa que não se usa atoa. Mas em um time onde todo mundo conhece, seja "clean code", mvc, ou qualquer arquitetura em camadas que seja de conhecimento comum, não acredito que isso aumente a complexidade. Patterns, são repetitivos, as pessoas olham e inituitivamente reconhecem as coisas. Garanto pra ti que o mundo do software sofre muito mais por código bagunçado onde cada um faz do seu jeito "simples", feito de qualquer maneira, do que pela tal do over enginering.

E todo projeto tem sua particularidade. Um projeto menor, não precisa ser implementado à risca o clean code. A questão das camadas é algo muito simples de se implementar. Por mais simnples que seja o sistema, colocar tudo dentro do controller achando que as coisas vão ficar mais simples ou mais rápidas, não vai resolver. Se você apenas separasse o seu caso de uso/service do controller e chamasse as operações de banco de outro de outro arquivo, injetando as dependências, essa simples separação já te colocaria em 70% do que é a clean arch. E foi feito o básico do básico na sua aplicação, sem comprometer em nada a legibilidade, a complexidade do seu projeto. Complexo é analizar um arquivo com 800 linhas....

Parece que o clean code é muito complexo na teoria, mas na prática é bem simples. Tem coisas que, seguindo boas práticas óbvias de desenvolvimento como o SOLID por exemplo, intuitivamente, o código fica "limpo". Não é uma questão de nomear pastas e arquivos, é onde as coisas devem ficar. Já viu um programador experiente, amontoar responsabilidades e acoplar funcionalidades em prol de "simplicidade" no código? Isso não existe, naturalmente, a sua aplicação vai ter camadas e em casos que você não quer acoplar uma lib externa, de repente um banco porque talvez você não confia, na verdade, não que você não confie no banco, mas talvez você não confie na estabilidade do ORM que você utiliza pra acessar o banco... seja qual for o motivo, esse tipo de desacoplamento é básico pra qualquer programador experiente. Não tem nada de complexo, trabalhoso demais ou mais lento em implementar isso.

A gente tem um monte de termos e nomes técnicos e bonitinhos pra falar de código, e que virou modinha, mas a verdade é que programadores experientes fazem isso a anos sem dar nomes aos bois. Ou o código está todo em seu devido lugar, não misturando muitas responabilidades, não muito acomplado, não se repetinfo muito, ou, o código está todo feito de qualquer jeito sem se preocupar com nada. Não tem muito pra onde correr, você pode odiar o termo, a modinha, mas a ideia toda, no núcleo, está correta. Talvez não esteja correta nos detalhes, mas essencialmenbte, falar mal de clean code, ao meu ver é insanidade.