Ola!
Em um projeto real usando MVC com uma camada de Services, esse script de atualização com updateOne não deveria ficar solto nem no Controller. O lugar mais adequado é o Service, porque é ali que vivem as regras de negócio. O Controller apenas recebe a requisição (HTTP ou Socket), extrai os dados necessários e delega a responsabilidade para o Service. Já o Model fica restrito a representar o schema e executar as operações no banco.
No curso, o update aparece de forma bem direta porque o foco é ensinar o método do MongoDB. Em produção, esse update quase nunca é “fixo”. Ele costuma ser dinâmico, montado a partir dos dados recebidos e das regras da aplicação. O Service é quem decide o que pode ou não ser atualizado, em que momento isso acontece e quais campos realmente devem ir para o updateOne. Assim você evita regras espalhadas e Controllers cheios de lógica.
Sobre a dúvida maior de arquitetura, dá para pensar assim: MVC puro funciona bem para projetos pequenos, com poucas regras e CRUD simples, mas costuma gerar Controllers grandes conforme a aplicação cresce. O MVC + Service já resolve isso muito bem e acaba sendo o padrão mais comum no mundo real, principalmente em Node.js. Ele organiza melhor o código, facilita testes e evita repetição de lógica. Já adicionar uma camada de Repository só faz sentido quando o projeto é grande o suficiente para justificar esse nível extra de abstração, como quando você precisa trocar o banco de dados com facilidade ou isolar completamente o acesso aos dados para testes. Caso contrário, é mais complexidade do que benefício.
E sobre o link da Alura, pode ficar tranquilo. Esse tipo de URL com parâmetro de usuário é comum no fórum e não expõe informação sensível, então não tem problema compartilhar. :)