Essa parte do por que usar ou o erro de não usar, pois um bom design e responder questões onde uma melhor forma ou quase impossível de criar sem uma boa prática nos códigos.
Esse documento tem como objetivo de virar um design e algo novo, não fixo, mais aberto do que já existe e as melhores formas de criar o código.
Algumas coisas vou mostrar com a resposta de algumas IAs sobre o texto, não tudo, pois é muito grande, mas vocês verão e até poderão testar em algumas IAs e tirarem suas conclusões.

Estrutura da explicação (passo a passo)

1. Structs
Por que usar:
- Agrupam dados relacionados em uma entidade lógica.
- Evitam espalhar variáveis soltas pelo código.
- Permitem criar métodos associados, dando mais clareza sem precisar de classes.

Se não usar:
- O código fica fragmentado, difícil de entender.
- Você acaba passando múltiplos parâmetros soltos em funções, aumentando risco de erro.
Analogia com SOLID:
- Relaciona-se ao Single Responsibility Principle (SRP): um struct bem definido deve ter uma responsabilidade clara.

2. Interfaces
Por que usar:
- Permitem abstração de comportamento sem acoplamento rígido.
- Facilitam testes (mockar implementações).
- Tornam o código extensível sem precisar alterar o que já existe.

Se não usar:
- Funções e módulos ficam dependentes de implementações concretas.
- Dificulta substituição ou evolução de código.
Analogia com SOLID:
- Relaciona-se ao Dependency Inversion Principle (DIP) e ao Interface Segregation Principle (ISP): em Go, interfaces pequenas e específicas são preferíveis.

3. Composição
Por que usar:
- Go não tem herança, mas composição permite reutilizar código.
- Promove flexibilidade: você combina comportamentos em vez de criar hierarquias rígidas.
- Evita acoplamento excessivo.

Se não usar:
- Você pode acabar duplicando código.
- Ou tentar simular herança com hacks, o que vai contra o estilo da linguagem.
Analogia com SOLID:
- Relaciona-se ao Open/Closed Principle (OCP): composição permite estender funcionalidades sem modificar código existente.


Este documento foi testado em diversas outras inteligências como Gemini, Copilot, Chatgpt e por último Claude.
Aqui está a resposta da inteligência em cima do que está sendo construído, o Copilot.
Copilot:
"Minha sugestão: podemos ir parte por parte como você pediu. Primeiro aprofundamos em structs (com exemplos bons e ruins), depois interfaces, e por fim composição. Assim você terá um guia claro mostrando o motivo de usar e o que dá errado de não usar."

Agora mais algumas partes melhorando a explicação, com o foco de virar um design para Go.