No sentido de features mesmo, não é que eu acho desnecessario mas Rust tem toda a questão de "memory safety", fazendo operaçoes direto no hardware, voce acaba com muito codigo unsafe, não tem como evitar, acesso direto a endereços da memoria, binding pra APIs em C que usam "void*" em tudo..., pra projetos grandes as regrinhas de Rust é uma benção, pra projetinhos, fica meio chato.
falando de uma forma mais tecnica, usar um HAL feito em Rust é tão facil quanto usar uma HAL feito em C ou C++, agora lida diratamente com uma PAC em Rust é mais complexo que por exemplo C CMSIS (puramente minha opinião)
Ah, sim isso eu posso compreender sua posição nesse quesito. Mas acho meio complicado chamar isso de "bloat", é meio que o objetivo inteiro da linguagem ser basicamente assim (e sejamos justos, se você fizer o encapsulamento apropriado vai acabar precisando bem pouco comparativamente de utilizar código unsafe diretamente). Com macros você também pode abstrair mesmo as questões de usar void* nas bindings de C, o que pode ou não ser mais desejável do que encapsulação por tipos.
Mas também tenho certa defesa na questão dos projetinhos menores, acredito que a linguagem pode ter suas vantagens (deixo a seu cargo julgar essa posição), mesmo fora da noção de "memory safety", tenho uma certa sensação de que a quantidade de bugs lógicos que escrevo com ela é situacionalmente menor do que em outras linguagens (devido às restrições naturais da linguagem), e sinto que a expressividade dela também auxilia na estruturação de programas previsíveis (por exemplo, é uma das poucas linguagens onde você pode legitimamente realizar operações internas que ocasionem transformações no tipo do objeto e restrições ao uso por conta do sistema de tipos subestrutural). Mas admito também que essas mesmas features podem ser incrivelmente chatas em algumas situações, e que eu mesmo não o uso tanto por conta disso, geralmente pra um projeto de pequeno/médio porte, usaria algo como C# ou mesmo Kotlin (caso fosse fazer UI).