I understand your answer is in good faith, but it still sounds like the same generic answer given when someone questions the engineering quality of any other popular product or service.

The fact is that plenty of teams are mature and professional and yet most software still suffers from bloat, slowness, bugs. Why would React be different?

Preact, for comparison, is only 5kb or so, and has almost 1:1 feature parity. It's not fully drop-in without the compat, and even experienced React devs can nitpick about it, but that's not the point: the mere fact that it exists and gets the job done is enough to raise doubts about the need for React to be quite big.

Does React need to lose weight? Maybe, maybe not. But I don't think it's good to shut down those discussions.

I think the same generic answer _does_ apply to most mature projects. Libraries like these should be approached like discussions about starting over in mature software projects; "this time we'll do it correctly", or "this framework is much simpler". This applies very much to libraries such as these.

When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.

Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?

Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.