Quando você escolheria um dataclass em vez de um NamedTuple ou um modelo Pydantic?

Use dataclass para estruturas internas mutáveis onde você quer atributos comuns e init, repr e eq de graça. Use NamedTuple quando quiser um registro imutável, parecido com tupla, que desempacota e faz hash barato. Use Pydantic nas fronteiras do sistema, onde você precisa de validação em runtime, coerção e serialização de dados chegando de HTTP, arquivos de configuração ou filas.

Minha regra é que o Pydantic guarda as bordas e os dataclasses vivem por dentro. Qualquer coisa cruzando uma fronteira, um corpo de request, uma configuração de ambiente, uma mensagem vinda de uma fila, ganha um modelo Pydantic porque eu quero aquilo validado e coagido uma vez, de forma barulhenta, no ponto em que chega. Tudo depois disso pode ser um dataclass simples com slots ligado, já que eu sei que os dados estão bons e não quero pagar custo de validação em cada objeto que construo num loop. O que as pessoas esquecem é que anotar um campo de dataclass como int não faz nada em runtime, então passe uma string e ele guarda a string numa boa. NamedTuple eu uso menos, principalmente para registros pequenos e imutáveis que precisam ser chaves de dict ou ser desempacotados, tipo um par de coordenadas ou uma chave de cache. Num serviço em que trabalhei, trocar um caminho quente interno de modelos Pydantic para dataclasses com slots cortou o tempo de um job em lote de forma perceptível, puramente por pular a revalidação de dados que já tínhamos checado.