Concordo com você em tudo, porém queria explicar essa sua afirmação: Então não há a menor necessidade de ficar fazendo malabarismos .

Cara, no codewars tem todo tipo de dev. grade parte deles partilham a sua linha de pensamento, por exemplo, essa solução, além de muitas outras, teve muita crítica sobre os pontos que você tocou na sua resposta, porém, tem muito dev que só quer se "divertir", parece que o lema deles é: Quanto mais exótico melhor. Alguns tentam resolver tudo em uma única linha ( São as soluções com mais críticas ) outros "10 linhas é pouco". É um lugar para todo tipo de dev, é por isso que algumas soluções tem todo esse marabalismo, já que alguns devs não querem codar o "mais óbvio". Usando um outro desafio pra defender meu ponto kkk.

Desafio: Uma função que recebe uma string e retorna o inverso dela.

As soluções com mais votos de boas práticas eram as que usavam métodos build-in. Mas teve uma solução que teve um pouco de crítica, por não seguir boas práticas.

   inverse = lambda _str: _str[::-1] 

É nessas soluções exóticas que eu aprendo como usar oque leio na documentação. Espero que esse texto te faça entender o porquê dos marabalismos. eu sei que eu deveria ter colocado algo como: "Não use esse tipo de coisa em produção". Mas como nem trabalho na área, essa informação passou despercebida.

Eu não participo do codewars, mas pelo que vc disse, parece que essa "criatividade" é incentivada, então tudo bem.

Mas pra código em produção, em projetos sérios, que vai ser mantido por outras pessoas, clareza e simplicidade costumam ser características mais desejáveis do que tentar ser "esperto" ou exótico.

Já essa forma de inverter string não achei ruim, slices servem pra isso mesmo (não tem nada de exótico, pelo menos pra quem conhece a sintaxe, que inclusive está bem documentada).

Infelizmente sim, quando eu termino um desafio, sempre vou procurar por soluções assim. um ponto bom é que tem muito dev bom, explicando o porquê não usar. Eu mesmo costumava usar muito o operador ternário no javaScript, mas le muito comentário sobre isso afetar muito a legibilidade do códico. É como vc disse, soluções "exóticas e espertas" não são uma boa para códico em produção. Agora ficarei mais "de olho" nessas soluções, ainda continuarei buscando-as nas soluções, pra saber oque não fazer. Obrigado por isso.