Veja, você está trabalhando com dois conceitos distintos: é possível pegar os jars “na unha” e colocar num ponto específico utilizando o eclipse.
Da mesma maneira, é possível trabalhar com maven e NB.
Agora, vamos lá: não considero usual a troca de jars em um projeto. Se isso ocorre, alguma coisa não está correta: falha no planejamento, em geral. Faltou algo ou o projeto foi ampliado. Nas duas situações, é preciso criar um novo artefato e enviar ao cliente (ou fazer a compilação no cliente, evitando, assim, que você crie um artefato enorme).
Outro ponto é que, mesmo para projetos antigos, nunca vi trocar a versão de uma dependência para outra. Isso pode quebrar muito do teu código e causar um impacto ainda maior. Sem falar que eu não vejo vantagem em, dentro de um universo de 200 jars, atualizar 3 ou 4 e manter mais de 190 antigos. Qual a lógica nisso?
Agora, meu testemunho: quando eu comecei a desenvolver, não entendia maven. Não achava aquilo necessário e, como essa p0rr@ precisa de um XML pra configurar, eu odiava mais.
Sempre achei muito mais simples ir lá, caçar um jar aqui, 10 ali, 20 acolá e juntar tudo.
Os duplicados removia manualmente e boa.
Aí, um belo dia, caí num projeto que me forçou usar essa disgrama.
Hoje eu não crio projetos sem ser maven project (exceto no Android Studio, que tem o gradle).
O que fica de lição: não nade contra a corrente, é mais fácil.