TL;DR
In HTTP/1.1, you had to make as few requests as possible to get performance; in HTTP/2 you have minimal performance impact per request but can still hit resource constraints and dependency management that will require a bundling tool such as webpack.
Long version:
Webpack (or any other bundler) can still provide value in an HTTP/2 world because while HTTP/2 allows multiplexed, asynchronous, simultaneous queries from the client to the server, it doesn't mean that the actual server you're connecting to has unlimited capacity to process them or will even allow them.
In the SETTINGS frame sent when you connect, most servers will restrict the number of concurrent streams to a reasonable value such as 100. This means you can not issue more than 100 concurrent requests, which is an issue if you have for example a large unbundled React app with hundreds of js files.
Furthermore, in many cases, you have transitive dependencies between javascript files and if you don't bundle all the dependencies, you'll need many request round-trips as the browser will only discover dependencies when it receives the previous responses, negating HTTP/2 benefits. (Alternatively the server may be able to push automatically the dependencies but this creates a whole other set of issues).
For these reasons, it makes sense to use webpack to package a number of homogeneous bundles to make sure your maximum concurrent requests stay below the server limits while keeping your bundle granular enough to leverage efficient browser caching.
