Só uma coisa, esse código é PHP? Porque se for, ele nem sequer chega a rodar, porque return echo dá um erro de sintaxe (mas mesmo que não desse erro, não faz sentido, porque echo sequer retorna um valor). Se a ideia é imprimir e sair, teria que ser echo em uma linha e return; na seguinte. Enfim...

De qualquer forma, isso não necessariamente melhora a eficiência. Fiz alguns testes com JS, usando o Benchmark.js, e houve um empate técnico entre fazer com ou sem else. Testei também com Python (usando o módulo timeit) e novamente, empate técnico. Em outras linguagens meu palpite é que seria parecido (a menos que o PHP tenha algum detalhe de implementação específico).

Claro que nesse caso a função é muito simples, mas enfim, eficiência depende mais de outros fatores, como por exemplo o branch prediction - dependendo da implementação, do hardware, do algoritmo e até mesmo dos dados usados no caso real, toda essa combinação de fatores pode influenciar mais no desempenho do que se usar ou não early return.

Eu vejo o early return muito mais como uma ferramenta semântica do que algo para melhorar a eficiência. Aqui tem uma discussão bem interessante sobre o assunto, inclusive um dos casos discutidos é sobre "fail fast", ou seja, primeiro eliminar os casos de erro/inválidos, e depois partir para o "trabalho" em si. Algo como:

function fazAlgo(params) {
    if (!validacao1(params)) {
        return ERRO1;
    }
    if (!validacao2(params)) {
        return ERRO2;
    }
    // etc (várias validações diferentes)

    // se chegou aqui, é porque todas as validações passaram, então sei que os dados estão corretos
    // e posso fazer aquilo que de fato a função faz
}

Outro exemplo:

public int someFunction(String name, int value, AuthInfo perms) {
    int retval = SUCCESS;
    if (someCondition) {
        if (name != null && !name.isEmpty()) {
            if (value != 0) {
                if (perms.allow(name)) {
                    // processa os parâmetros (aqui é o que a função realmente faz)
                } else {
                    retval = PERM_DENY;
                }
            } else {
                retval = BAD_VALUE;
            }
        } else {
            retval = BAD_NAME;
        }
    } else {
        retval = BAD_COND;
    }
    return retval;
}

E a versão mais legível, com early return:

public int someFunction(String name, int value, AuthInfo perms) {
    if (!someCondition)
        return BAD_COND;
    if (name == null || name.isEmpty())
        return BAD_NAME;
    if (value == 0)
        return BAD_VALUE;
    if (!perms.allow(name))
        return PERM_DENY;

    // processa os parâmetros (aqui é o que a função realmente faz)
    return SUCCESS;
}

Nesse caso o ganho foi em legibilidade e clareza (além de deixar a manutenção mais fácil), mas não necessariamente em eficiência (pra isso precisaria testar com casos reais, e provavelmente o gargalo estaria em outra parte - raramente essa sequência de if's é o principal problema de desempenho).

E reforçando o que os demais disseram, não devemos nos apegar cegamente a esses "mantras" arbitrários do tipo "nunca use X" (ou "sempre use X"). Como qualquer coisa em computação, o mais indicado é saber como cada coisa funciona, entender seus prós e contras, e com base nisso decidir quando usar. No caso do else, que é uma das estruturas mais básicas da programação, não é diferente.