Para quem está começando, eu diria que está bom. Mas tem alguns detalhes que acho bom já ir adiantando. Embora pareça "pesado" para um iniciante, acho interessante pelo menos já pincelar alguns assuntos, pra vc não pegar certos vícios que são difíceis de tirar depois.
Linguagem Compilada vs Linguagem Interpretada
O JavaScript é uma linguagem interpretada, portanto não precisa do processo de compilação.
Na verdade, o buraco é bem mais embaixo. Sei que muita gente faz essa simplificação, mas hoje em dia as coisas estão mais nebulosas e esta separação entre linguagens "compiladas" e "interpretadas" não é mais tão simples assim.
Primeiro (e estou sendo bem pedante): uma linguagem, a grosso modo, nada mais é que uma especificação—um ou mais documentos que descrevem a sua sintaxe, comandos, funcionamento, etc.
É claro que para a linguagem ser útil e podermos escrever programas com ela, precisa ter alguma implementação. Basicamente, um compilador/interpretador para rodar o código. Mas a linguagem em si (a especificação, a sintaxe e forma de funcionamento) não é compilada ou interpretada. As diferentes implementações desta linguagem podem usar um compilador ou interpretador.
O que ocorre é que na prática, a maioria das linguagens acaba tendo uma ou duas implementações mais populares, e estas acabam sendo usadas para definir se a linguagem é interpretada ou compilada. Mas lembre-se que isso é uma característica da implementação, não da linguagem (a menos que alguém diga na especificação que só pode ser um ou outro, mas na prática não fazem isso). Ou seja, é tecnicamente possível ter, por exemplo, interpretador de C (embora não seja nada prático).
E mesmo se considerarmos a implementação, hoje em dia elas estão tão complexas que é difícil cravar se é uma coisa ou outra.
Tá, e o JavaScript é o que então?
Atualmente as implementações mais comuns são o V8 (usada pelo Node.js, Deno, e também pelo Google Chrome e todos os browsers que se baseiam no Chromium) e o SpiderMonkey (usado pelo Firefox). Existem outras, mas são menos usadas.
Muitas destas implementações pegam o código JavaScript e geram um bytecode (um "código binário intermediário"), que depois é executado por uma máquina virtual (virtual machine, ou simplesmente "VM"). E durante a execução (em algumas engines, não sei se em todas) existe ainda um compilador JIT (Just-in-Time Compiler), que pode pegar trechos do bytecode e compilá-los para código de máquina.
Então o V8 e o SpiderMonkey são o que? Eles compilam o código fonte, mas em vez de gerar código de máquina, geram um bytecode. E eles possuem uma VM que executa o bytecode (e muitos dizem que ele "interpreta"). Mas o JIT é outro compilador que atua no bytecode (no código que já foi "compilado"), e gera código de máquina. Então partes são compiladas e outras, pode-se dizer que são interpretadas. Daí a conclusão é que são compiladores ou interpretadores? Ou ambos?
E olha só, é exatamente assim que funciona em Java e C#: o código é compilado, vira um bytecode que é executado por uma VM, que por sua vez possui um JITter, que compila o bytecode e gera código de máquina. Então por que costumam dizer que essas linguagens são compiladas e JavaScript é interpretado? Meu palpite é que essa impressão existe porque no Java cada etapa é feita separadamente (vc "vê" o compilador em ação, afinal), enquanto que no JavaScript é tudo feito de uma vez, muitas vezes debaixo dos panos (como quando ele executa no browser, por exemplo).
Só pra citar outro exemplo, em Python também é feito assim (código -> bytecode -> VM). A única diferença é que na implementação mais comum (o CPython) não tem JIT (embora existam propostas para ter), mas o PyPy (que é outra implementação da linguagem) tem.
Enfim, se for para fazer simplificações, tudo bem. Mas saiba que essa história de "compilado" x "interpretado" é mais complicada do que parece. Leitura adicional:
Sobre o código
Sei que muita gente diz - e até ensina em "cursos" - que tanto faz, mas eu diria para colocar ponto-e-vírgula no final das linhas. Pode parecer "frescura", e sei que o JavaScript "aceita" o código sem ponto-e-vírgula e "funciona", mas isso evita algumas situações bizarras que podem ocorrer se você não usá-los, como essa e essa (veja mais sobre isso aqui).
Não precisa declarar a variável let resultadoMedia fora da função. Não faz sentido, já que ela é o resultado de cada invocação da função. Imagine se vc chamar a função várias vezes, para diferentes arrays. Cada vez que ela executar, a variável será alterada. Mas pra que alterar uma variável externa à função, se este valor só faz sentido lá dentro? Então poderia ser:
function calcMedia(numeros) {
let soma = 0;
for (let i = 0; i < numeros.length; i++) {
soma += numeros[i];
}
return soma / numeros.length;
}
Repare que na verdade eu nem usei a variável. Se vc só quer retornar o resultado e não vai usar para mais nada, então nem precisa da variável, pode retornar o resultado do cálculo diretamente.
Se eu quiser jogar o valor da média em uma variável, eu faço isso fora da função:
const mediaAluno1 = calcMedia(notasAluno1);
const mediaAluno2 = calcMedia(notasAluno2);
Ou seja, se precisar de uma variável, eu crio. Da forma que vc fez, resultadoMedia seria alterada cada vez que a função fosse chamada, e não tem motivo nenhum pra fazer isso. Mantenha tudo dentro da função, e se precisar guardar o valor em uma variável, faça-o fora da função, pegando o retorno da mesma.
E repare que na função eu mudei o nome do parâmetro para numeros (no plural), assim fica mais claro que pode ter vários números ali. num dá a impressão de que é um só. Sei que ao ler o código, dá pra presumir que é um array, mas ainda acredito que dar nomes melhores ajuda muito na hora de programar. Deixa o código mais claro para quem for ler (não só vc, mas outras pessoas da sua equipe - e até mesmo vc no futuro) e diminui a carga cognitiva (que no médio e longo prazo cansa bastante).
Por fim, como curiosidade, existe também o for..of:
function calcMedia(numeros) {
let soma = 0;
for (var n of numeros) {
soma += n;
}
return soma / numeros.length;
}