Qual è il vantaggio di questo modello di attore per i gestori HTTP in go

Ho letto alcuni blog e più recentemente ho parlato del discorso di Peter Bourgon intitolato "Ways to do things". Mostra alcuni esempi del modello di attore per la concorrenza in GO. Ecco un esempio di gestore che utilizza tale modello:

func (a *API) handleNext(w http.ResponseWriter, r *http.Request) {
    var (
        notFound   = make(chan struct{})
        otherError = make(chan error)
        nextID     = make(chan string)
    )
    a.action <- func() {
        s, err := a.log.Oldest()
        if err == ErrNoSegmentsAvailable {
            close(notFound)
            return
        }
        if err != nil {
            otherError <- err
            return
        }
        id := uuid.New()
        a.pending[id] = pendingSegment{s, time.Now().Add(a.timeout), false}
        nextID <- id
    }
    select {
    case <-notFound:
        http.NotFound(w, r)
    case err := <-otherError:
        http.Error(w, err.Error(), http.StatusInternalServerError)
    case id := <-nextID:
        fmt.Fprint(w, id)
    }
}

E c'è un loop dietro le quinte che ascolta il canale action . La mia domanda è qual è il vantaggio di tutto questo? Il gestore non è più veloce perché sta ancora bloccando finché qualche azione nella funzione action non restituisce qualcosa. Che è essenzialmente la stessa cosa che restituire semplicemente la funzione dall'esterno della routine go. Cosa mi manca qui?