Em geral eu não gosto de artigos do tipo "não use X" ou "sempre faça Y". Muitas vezes eles usam apenas exemplos em que o uso (ou não-uso) é a melhor solução, e raramente mencionam os casos opostos (em que "quebrar a regra" seria benéfico). Ou só mencionam por cima que existem "exceções".

Não me entenda mal, eu acho importante saber sobre complexidade ciclomática, mas da forma que foi apresentado, um monte de iniciantes pode ler e achar que else é "do mal", ficar com medo de usar ou achar que tem algo errado em usá-lo, e acabar deixando o código pior só pra evitá-lo.

Sendo que existem casos legítimos para usar else, e nem sempre fica melhor tentar eliminá-lo a todo custo. Aliás, praticamente tudo em computação é assim, pra todo recurso e tecnologia existem casos de uso legítimos e situações em que existem soluções melhores. E também tem casos em que tanto faz.

Por exemplo, o early return:

function fazAlgo() {
    if (condicao)
        return;
    // Faz o resto
}

Nesse caso é OK, a condição indica uma situação na qual a função deve ser encerrada.

Mas e se tiver algo assim:

function fazAlgo() {
    if (condicao) {
        // Faz algumas coisas
    } else {
        // Faz outras coisas
    }
    // Faz o resto
}

Neste caso não tem como fazer o early return, pois existe um trecho que deve executar sempre depois do if/else, independente da condição ser verdadeira ou falsa.

Até daria pra argumentar que poderia quebrar em várias funções:

function cond() {
    if (condicao) {
        // Faz algumas coisas
        return;
    }
    // Faz outras coisas
}

function depoisCond() {
    // Faz o resto
}

function fazAlgo() {
    cond();
    depoisCond();
}

Mas aí precisa avaliar se vc escolheu desta forma porque faz sentido separar as funções (elas executam tarefas distintas e não faz sentido estarem juntas, por exemplo), ou se foi só pra poder evitar o else a todo custo. Se foi apenas pela segunda opção, então pra mim complicou o código à toa, pois o else na primeira versão do código não faz mal nenhum neste caso.

E na boa, independente da solução escolhida, vc continua tendo duas situações pra testar: uma na qual a condição é verdadeira, e outra na qual é falsa. O fato de eliminar o else não mudou isso.

O que acontece é que cada ferramenta pode avaliar de forma diferente cada um dos códigos e te dar a falsa impressão de um deles sempre ser "melhor". Por exemplo, algumas ferramentas (como o Sonar) consideram que cada return a mais adiciona complexidade, então o early return seria considerado "mais complexo". Outras ferramentas podem avaliar de forma diferente.

No fim, o ideal é sempre saber pra que serve e como funciona cada coisa, e usar a melhor opção de acordo com o contexto, em vez de se apegar a regrinhas ditas "universais", que dizem pra nunca (ou sempre) usar sem avaliar o que faz mais sentido.