Any slow app would be just as slow if the team had built it using different tech, because it's the design of the software that makes it slow, not the framework.
There is no framework that has a "pit of success" that makes it inherently easy to build a fast app, so any team that uses a framework poorly is just as likely to use a different framework poorly. If they switch and things improve it's probably because the new framework happens to fit their mental model rather than any inherent function of the framework itself.
A good team that designs their code to make the most of a framework could write a good, fast app using any particular tech.
I've spent a lot of time thinking about what the "pit of success" looks like for a framework to make it inherently easy to build a well performing app ("fast" is a different subjective matter), even in some of the worst cases of a naive developer doing naive things. (I think I got really close to a "pit of success" with Butterfloat if you enjoy working with RxJS. Its defaults are tuned for smooth performance even if you are doing too much work in a component.)
There's no framework that has a "pit of success" on every subjective performance quality metric, but I do think some frameworks more than others have larger "pits of failure" that make it too easy to get bad performance even doing what you think is supposed to be the right thing. Because I've vocally picked on it many times at this point, an easy example to mind is Angular's Zone.js is a big opaque library that can accidentally drop you into a "pit of failure" without you realizing how you got there. I'm glad a couple years after I raised some warning flags about Zone.js that Angular is finally addressing that elephant in the room and removing Zone.js as the suggested option and are close to removing it as the default option.
(I'm less glad that the reason that finally pushed them to do that is adding Signals. It seems wild to me to have proper Observables and also Signals and that just seems like another potential pit full of accidentally doing the wrong thing because it looks easy but the interactions between imperative code, Signals, and Observables is going to necessarily be complex and fraught with scheduling problems. I can't say that I'm surprised that Angular development is again moving one step forward while also two steps back at the same time.)
I know others with similar rants about React Hooks and how easy it is to miss needed dependencies in the dependency list of a Hook and too easily fall into a pit of failure.
It is useful to evaluate frameworks with some small eye to "how hard does this make it to do performance right if we follow its 'best practices', even in the case of simple mistakes?"
There is no framework that has a "pit of success" that makes it inherently easy to build a fast app, so any team that uses a framework poorly is just as likely to use a different framework poorly. If they switch and things improve it's probably because the new framework happens to fit their mental model rather than any inherent function of the framework itself.
A good team that designs their code to make the most of a framework could write a good, fast app using any particular tech.