Don't let bad frameworks represent all frameworks. That is a faulty generalization [0].
If you qualify this advice to the point where it actually becomes useful it turns into, "Use code written by other people that doesn't suck." And that, of course, is indeed a good idea, but it's a lot easier said than done.
But despite that caveat, there do exist frameworks out there today that speed up development for some developers. Whether one has the time or energy or will to audit them to find one that works best for them (or learn that none of them do) is up to the individual.
I bring this up because many of us on this website are at times infected by NIH syndrome and think we can do better than a dedicated team of experienced front-end developers. And it's likely true for many frameworks, but not all. Additionally, we may want to extend that attitude to our workplace where our peers and bosses likely value development speed and cross-project consistency over code performance.
I used to eschew any and all frameworks, but now I realize that my values have changed. Projects like Svelte give me hope for a better future for front-end development.
Of course. But there also exist frameworks that will slow development down. For any X in {frameworks, languages, operating systems, libraries} there exist X's that will be helpful and X's that will not, and so "use an X" by itself is not helpful advice for any X. You have to use a good X, but that isn't helpful either because it just begs the question.
I just intended to push back against the notion that frameworks should not be considered.
I'd say there's quite a bit "special" about all of these attributes, at least enough to warrant careful consideration.