Faz sentido dividir uma interface multi-método existente em várias interfaces de método único apenas para aproveitar lambdas?

Digamos que eu tenha uma interface de retorno de chamada existente que tenha vários métodos. Para ilustrar o meu ponto, eu uso um callback dos gostos que você veria no código que executa algumas operações do cliente HTTP:

public interface GetCallback<T> {
    public void onSuccess(T data);
    public void onAuthFailure();
    public void onError(RequestError error);

    //Potentially more methods like onPreGet etc...
}

E um método que faz uma solicitação levaria uma instância desse retorno de chamada como um argumento:

public void issueRequest(String url, GetCallback<T> callback) {
    // Implementation ...
}

Como é óbvio, isso sofre com verbosidade no site da chamada:

public void getData(){
    issueRequest("http://programmers.stackexchange.com", new GetCallback<String>(){
        public void onSuccess(String data) {/*Do Something*/}
        public void onAuthFailure(){/*Ask for credentials*/}
        public void onError(RequestError error){/*Show error message*/}

    });
}

Eu tenho algo semelhante no meu código e está funcionando bem. Eu uso uma classe DefaultGetCallback que fornece a implementação padrão dos métodos onAuthFailure e onError , pois a ação que eu quero executar nesses casos é praticamente a mesma, independentemente do recurso que estou solicitando.

A questão é, faz sentido refatorar isso em uma classe composta de um conjunto de interfaces de método único para aproveitar a sintaxe lambda?

public class GetCallback<T>{
    public interface OnSuccessListener<T> {
        public void onSuccess(T data);
    }

    public interface OnAuthFailureListener {
        public void onAuthFailure();
    }

    public interface OnErrorListener {
        public void onError(RequestError error);
    }

    private OnSuccessListener mSuccess;
    private OnAuthFailureListener mAuthFailure;
    private OnErrorListener mError;

    public GetCallback<T>(OnSuccessListener<T> success) {
        this.mSuccess = success;
    }

    public GetCallback<T> withAuthFailure(OnAuthFailureListener authFailure){
        this.mAuthFailure = authFailure;
        return this;
    }

    public GetCallback<T> withError(OnErrorListener error){
        this.mError = error;
        return this;
    }

}

Eu poderia usar um padrão Builder para construir o GetCallback , mas isso é além do ponto. O site de chamadas agora se torna:

public void getData(){
    issueRequest(
        "http://programmers.stackexchange.com", 
        new GetCallback<String>(s -> doSomething(s))
            .withAuthFailure(() -> askForCredentials())
            .withError(error -> showErrorMessage(error))
    );
}

Uma vantagem é que eu posso personalizar o comportamento de "eventos" individuais (sucesso, erro, etc.) isoladamente, no site de chamada, em vez de ter que criar uma subclasse ou criar uma classe interna anônima.

Mas então, quanto é demais? Especialmente considerando o fato de que meu design atual já me serviu bem?