Massa demais, principalmente a parte da Mutation, era básicamente onde estava o maior 'gap'. Eu tinha essa ideia do motivo de ser uma 'vantagem' trabalhar dessa forma, mas essa parte

Dados imutáveis são naturalmente seguras para uso em threads, pois não existem problemas com múltiplas threads tentando modificar os mesmos dados simultaneamente. Já que ninguém pode modifical o dado. Isso facilita a escrita de código concorrente e paralelo de forma segura.

conseguiu me fazer compreender bem a importância. E faz todo sentido, é o famoso caso, depois que entende parece óbvio :).

Sobre a questão da programação funcional, ótimo, e você pegou num ponto que eu justamente me perguntava, "Um loop e recursividade não são a mesma coisa?", mas isso é só um detalhe, curti a ideia de 'experimentar' as linguagens citadas, farei isso.

Você me confirmou o que já pensava do 'Event Loop', acredito que no final esse seja o conhecimento mais importante de ter, independente de querer definir o que é mais importante que o que, tudo é, mas de modo geral acho que a parte de entender como o código vai 'rodar' é algo direcionado a eficiência do mesmo, estou correto nessa análise? Não só eficiência como evitar bugs com race conditions. Na verdade acabei de ler e vi que você cita isso mesmo

Problemas como bloqueio do thread principal, gerenciamento ineficiente de tarefas assíncronas e outros problemas de performance estão frequentemente ligados a um entendimento insuficiente do Event Loop. Um conhecimento sólido nessa área é fundamental para evitar esses problemas.

Sobre o async await isso foi o que me 'quebrou' na verdade, a um bom tempo eu venho usando isso constantemente, de uma forma que a minha cabeça começou a julgar uma Fn async como sendo de 'thread principal', blocante/bloqueante, e eu tava considerando começar a trabalhar com callbacks (na verdade eu só preciso pensar mesmo, o fluxo de async await faz parecer que estamos trabalhando um código sync, mas já aprendi, justamente depois dessa pergunta)

Sobre a ultima, sobre Jr, Pleno, Sr, na verdade essa foi uma pergunta mal feita da minha parte, na verdade a ideia era tentar definir o que eu deveria estudar, o que eu devo focar pra me tornar um bom profissional, no final eu até considero essa pergunta 'idiota', porque níveis de senioridade são muito vagos, acredito que ao invés de perguntar 'Se eu não sou Jr etc...', eu deveria perguntar algo como: "O que devo aprender quando sai do CRUD?" Lógico, a resposta pode ser tudo, e por isso que tentei passar a ideia de "O que é conteúdo pra Jr?" "E o de pleno" "E o de Sr", essa era a ideia, pra eu não querer ver algo complexo demais sem ter estudado a base antes.

Mas voltando, muito foda, muito obrigado pelas respostas, conseguiu destravar os neurônios.

No final, analisando a pergunta, ficou parecendo até que eu fiquei com raiva do 'entrevistador' porque ele não me considerou nem um Jr... muito mal feita essa minha colocação.