No mundo dos logs, existem Fachadas (como Apache Commons Logging, slf4j ou até a API Log4j 2.0) e implementações (Log4j 1 + 2, java.util.logging, TinyLog, Logback).
Basicamente, você deve substituir seu invólucro selfmade por slf4j IF e somente se você não estiver satisfeito com ele por algum motivo. Enquanto o Apache Commons Logging não está realmente fornecendo uma API moderna, o slf4j e a nova fachada do Log4j 2 estão fornecendo isso. Como vários aplicativos usam o slf4j como invólucro, pode fazer sentido usá-lo.
O slf4j fornece uma série de ótimos açúcares de API, como este exemplo do slf4j docs:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
É substituição variável. Isso também é suportado pelo Log4j 2.
No entanto, você precisa estar ciente de que o slf4j é desenvolvido pelo QOS, que também mantém o logback. O Log4j 2.0 é instalado na Apache Software Foundation. Nos últimos três anos, uma comunidade vibrante e ativa cresceu lá novamente. Se você aprecia o Open Source, como é feito pela Apache Software Foundation, com todas as suas garantias, pode reconsiderar o uso do slf4j em favor do Log4j 2 diretamente.
Observe:
No passado, o log4j 1 não era mantido ativamente enquanto o Logback era. Mas hoje as coisas são diferentes. O Log4j 2 é mantido ativamente e é lançado com agendamento quase regular. Ele também inclui muitos recursos modernos e -imho- faz algumas coisas melhores que o Logback. Às vezes, isso é apenas uma questão de gosto e você deve tirar suas próprias conclusões.
Escrevi uma rápida visão geral sobre os novos recursos do Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html
Ao ler, você verá que o Log4j 2 foi inspirado pelo Logback, mas também por outras estruturas de registro. Mas a base de código é diferente; ele compartilha quase nada com o Log4j 1 e zero com o Logback. Isso levou a algumas melhorias, como no exemplo, o Log4j 2 opera com bytestreams em vez de Strings under the hood. Também não perde eventos durante a reconfiguração.
O Log4j 2 pode registrar com maior velocidade do que outras estruturas que conheço: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
E ainda a comunidade de usuários parece ser muito maior que o Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html
Dito isso, a melhor idéia é escolher as estruturas de registro que melhor se ajustam ao que você deseja alcançar. Eu não mudaria uma estrutura completa se desativasse o log no ambiente de produção e apenas realizasse o log básico no meu aplicativo. No entanto, se você fizer um pouco mais com o registro, observe os recursos fornecidos pelas estruturas e seus desenvolvedores. Enquanto você obtém suporte comercial para o Logback por meio do QOS (ouvi dizer), atualmente não há suporte comercial para o Log4j 2. Por outro lado, se você precisar fazer o log de auditoria e precisar de alto desempenho fornecido pelos apêndices assíncronos, faz muito sentido verifique log4j 2.
Observe que, apesar de todo o conforto que eles oferecem, as fachadas sempre apresentam um pouco de desempenho. Talvez não esteja afetando você, mas se você estiver com poucos recursos, poderá precisar salvar tudo o que puder.
Sem conhecer melhor os requisitos, é quase impossível fazer uma recomendação. Apenas: não mude só porque muitas pessoas mudam. Mude apenas porque você vê o valor dela. E a argumentação de que log4j está morto não conta mais. Está vivo e está quente.
AVISO LEGAL: Atualmente, sou VP, Apache Logging Services e também estou envolvido no log4j.