What's the real use-case?

Developers like to code in the latest and greatest, without waiting for browsers to catch up. Many companies still have to support internet explorer, which doesn't support a lot of new javascript features. Using a babel loader makes transpiling your "new hotness" code to run in older browsers very easy. Webpack can do that in the build automatically. Many developers like to use Sass as a tool to write more powerful CSS, but again, the browser can't read Sass files. So we must convert them to CSS. Webpack can do that in the build automatically. Web sites are all about speed. Companies want pages to load as fast as possible. Have you ever heard of a street racer that takes all the unnecessary parts from their car (like passenger seats) in order to reduce the weight, making them go faster? Similarly, developers uglify or minify their code to strip the code to the bare minimum to reduce script load times, even going as far as reducing unneccesary spaces and line breaks. Even changing your function and variable names to single letters. Webpack can do that in the build automatically. When developing for the web it's usually a good practice to have functions do one thing really well, this lends itself to more modular code, which leads to creating more JS files and more CSS files, as you're separating the concerns. For example, with webpack you could have a separate CSS file for each module that you're working on in your code. That way you don't have to sift through one super long CSS file and look for your comments, you just go to the one that is specifically labeled for the piece you're working on. The problem at the end is: you would then need to link all of these JS and CSS files on your server, and every time the browser requests a page, it will need to send a request for these items to be downloaded. Each item will be a separate request, which isn't very efficient if you think about it. Webpack will bundles all of these files into one CSS file and one JS file etc. automatically during the build process and maintains the dependencies that exist between these files.

This is new to me but I understood the real use case to be related to optimised image loading. Url-loader encodes the image within the application package - therefore the browser doesn't have to make a separate request to the CDN or web server to load the image and performance of the application is improved.

There's a ton of possibilities (see the webpack docs for just a few examples), but it more or less comes down to getting file contents and transforming them into something else for use in your application.

You could do that manually with npm modules and a command line interface, but who has time for that?!