Se você tem tudo junto, modificou seu projeto (o código que você escreve) um novo bundle será gerado e terá que ser carregado novamente pelo navegador, pois ele não pode mais usar o que estava no cache.
Quando você separa, se mudou apenas o código que escreveu, o vendor não será modificado. Sendo assim, o navegador carregará apenas o bundle com sua lógica e não precisará carregar o bundle vendor que muda com menos frequência. Verdadeiro ganho para uma aplicação grande.
Além disso, se o bundle tem mais de 500k é um tiro no pé deixá-lo com esse tamanho. Pois em redes mais lentas e smartphones não tão potentes há um tempo de baixar e parsear os scripts. E a soma do tempo de baixar e passear pode empactar a UX do usuário que espera e nas pesquisas do Goggle.
Páginas que carregam rapidamente ganham ponto de rankeamento e com esse ponto podem aparecer no resultado de pesquisa na frente de página mais lentas.
Para completar, o loader do webpack baixa o bubdle em comum em pararelo, mas só executa seu código depois de tudo chegar.
Aprendemos que concatenar script é bom, mas quando o arquivo é grande demais isso causa problemas. O engenheiro front-end deve estar sempre de olho nesses pontos.
Mas isso não é suficiente, pois se o seu bundle com apenas seu código for grande demais, daí você precisará quebrá-lo em partes o que caracteriza a técnica chamada code spliting e lazy loading, pois ele só será carregado sonente quando o usuário precisar dele (Você aprenderá a fazer isso no curso).
Sugiro que você assista o curso:
https://www.alura.com.br/curso-online-otimizacao-performance-web
Lá você vê métricas e várias técnicas de otimização web.
Lembrando que Webpack é voltado para construção de SPA. Não tem a mesma finalidade de Gulp ou Grunt.
