While vite is perfect for most users, there are just some usecases that are not doable with meaningful performance. Without boring you with details why, let me assure you that having a performant webpack replacement for those 10% who need it, helps vite staying lean, as they are not bothered with feature creep.
If you want a small detail why: Vite is built on esbuild. Esbuild is carried by a single developer (https://github.com/evanw/esbuild/graphs/contributors) thus every nut and bolt that vite does for you on top is built in javascript, so you are in slow-land again.
webpack and turbopacks promise (and complexity) is that it treats these extras (plugins and loaders) as first class citizens and thus tries to make them as fast as possible by applying tons of caching. E.g. if you'd throw a webpack workflow at vite, you might end up with a slower build then webpack. And this is where turbopack tries to improve.
> Esbuild is carried by a single developer
The VC answer is to build something entirely novel and then fail to deliver.
They sponser https://github.com/kdy1 (see the vercel in his profile), who spearheads swc, which is very similar in goals and scope to esbuild. swc may ring a bell, as it's the parser/compiler that is used by deno and bun.
Source: check the language breakdown on zig's repo: 0% rust (what swc is written in).
Turbopack is made with that in mind.
That's not Vite's priority, it wants to have a novel approach without backwards-compatibility in mind.