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.