Hahaha, e eu acho que esse insight é bem válido.
De fato, olhando isoladamente para esse caso, um fieldset envolvendo um único input pode parecer rebuscado — principalmente porque o label já estabelece a relação com o campo através do id/htmlFor, e um fieldset sem legend não está explorando justamente uma das principais semânticas desse elemento. Semanticamente, fieldset foi feito pra agrupar vários controles relacionados; pra um par label+input, uma div faria o mesmo trabalho sem carregar uma semântica que não está sendo usada.
A intenção ali foi muito mais a de criar uma abstração para representar um campo do formulário, que pudesse encapsular a estrutura e o estilo desse conjunto — aquele display: flex; flex-direction: column; gap: 8px que ia se repetir em cada campo. Ou seja: o valor do componente está no padrão de composição que ele representa, não no elemento HTML escolhido pra implementá-lo. Tanto que, se você trocar o fieldset por uma div no CampoDeFormulario, o formulário continua funcionando exatamente igual. Vale fazer esse teste, inclusive — diz bastante sobre onde mora a responsabilidade de um componente.
E acho que é justamente uma discussão interessante: quando estamos criando componentes, precisamos tomar cuidado para não confundir "consigo transformar isso em um componente" com "isso deveria ser um componente". E, quando decidimos que deveria, ainda tem a pergunta seguinte: qual elemento HTML representa melhor o que esse componente é?
Então sim: seu "o que todos esses componentes de campo de formulário estão fazendo aqui?" é uma ótima pergunta. Inclusive, é exatamente o tipo de questionamento que eu gostaria que você fizesse ao olhar para o código.