Em parte é desempenho sim. Tem situações bem pontuais que é muito difícil conseguir extrair o máximo do C, fica mais fácil fazer em Assembly.

Há o caso de iniciar a execução do código que foi produzido pelo C, o que chama-se bootstrap, então precisa algo mais bruto, mas é um código pequeno demais.

Tem casos que é a interação com o hardware que não se consegue fazer, pelo menos de forma eficiente, com os mecanismos existentes em C. Para criar uma forma de fazer isso em C, daria muito trabalho e atenderia praticamente um caso de uso, então é melhor fazer em Assembly.

Tem código que é para interagir com o processador específico, então precisa de algo específico que o compilador C não pode gerar. Novamente, até poderia, mas não compensa fazer.

Tudo daria para criar em C, só não faz sentido infestar o compilador com isso. Afinal o compilador gera um código de máquina (Assembly é só um texto para humano entender melhor esses códigos), então não tem nada que seja impossível, só não está pronto.

É mais uma decisão que uma impossibilidade, embora isso aconteça em algo bem pontual.

O que não é, e muita gente acha que é, porque o Assembly é mais rápido que C. O Assembly tem mais condições de permitir que o programador faça algo mais rápido em algumas situações, embora costume ser mais difícil ou é algo muito fora do padrão. O Assembly não é inerentemente mais rápido que C. C não é que C++, que não é mais que C#. Há uma tendência a ser, desde que o programador faça bom uso e em alguns casos trabalhe bem mais duro. E olha que estou falando das implementações. É possível ter Assembly interpretado e ficará bem lento, só para citar um exemplo exagerado.

Tem dados que confirmam esses 3%? Eu imaginava que era inferior ou pouco acima de 1%.

Faz sentido para você?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).