I am an avid user of webpacker since day one.
- compiling scss
- scoped css
- autoprefixing css
- polyfilling browser behavior
- creating webfonts (or even iconfonts)
- static asset handling (inlcuding automatic resizing / compression, stripping assets of bloat)
Sprockets lacked (some / most of) these things, thus webpacker was a big, big step forward. Webpacker v6 as a very thin layer above webpack (in contrast to webpacker v5) even more.
Many of these things are quite essential if you have a huge codebase in frontend. It is my opinion that the wide usage of webpack has its reasons that are not mainly rooted in transpiling es6 (which is done in webpacker with babel, as one of many loaders that are used). The advantages lined out here in the mentioned blog post are also achievable with webpack(er).
That aside: The current release v5 of webpacker cannot be run in a safe way, as there are (known) security vulnerabilities. Not directly in webpacker, but in required (core) dependencies of it. The discussion seemed to reach consensus to not fix them but to wait for an v6 release of webpacker that - due to its awesome thin-layer-nature - automatically will resolve them / leave them to solve by the developer of the rails project using webpacker v6.
Worse: If you try to use webpacker v6 right now, you end up automatically with a very, very old release of webpacker v6 (pre.2) that is not even runnable as is. It caused a lot of headache and many hours of time to many users to find out, that beta.7 is actually the most recent v6 version of webpacker. So there are numerous comments on webpacker issues on github that just beg to at least release beta.7 under a different name. We need someone in charge of webpacker that can at least communicate what is needed to push it forward so that the community has even the chance to maintain it. But no one seems to care even if Rails 7 is not here yet and webpacker is currently the default nonetheless.
*edit: changed beta.6 to beta.7, thanks @PikachuEXE