Writing software in a fast language -vs- whatever quick-to-write-/maintainable-/domain-specific-/sandboxed-/etc. language is always some kind of compromise of perf. vs whatever your other priorities are. In particular, writing tooling for a language in that language will have massive advantages in terms of contributors, but may have perf. drawbacks if that language is not as performant as alternatives. Weighing up those pros & cons is important - the performant option is not always the best, it depends on your priorities.
Performance generally increases in priority depending on how much of a bottleneck it is. If webpack takes 0.2 seconds and esbuild would take 0.02 seconds, that's a 10x perf. gain but is probably not a compelling reason to switch. If webpack is taking 20 seconds however, that's a bottleneck that's worth looking at.
My point above is that an app that takes 20 seconds for webpack to build is overengineered in the most common cases - taking that badly written app and running it through esbuild to "fix" your problem isn't really fixing your problem, it's just hiding it under the bed. This is what's called "supporting dysfunction".
Numpy, pandas, scipy are poor comparators because they're processing data, not code: they're tasks that depend on data scale, rather than on how many over-abstracted layers of code someone is trying to compile all at once. The former is not (necessarily) a sign of dysfunction. It's much more likely to be a valid use-case.