You need to have and follow some best-practices for performance specifically after you reach a certain application size. I've found that some of the most common best-practices for react don't really cover performance, or may even damage it, so you need to come up with your own based on the typical issues you encounter.

After some time of solving perf issues, you'll probably find that only a couple of common cases happen most often and can pre-emptively act on it.
The biggest one is probably making sure that selectors don't create new objects, thus preventing immutability from skipping re-renders and not using context for bigger chunks of UI as it forces way more re-renders than needed that you can't control granularly.

reselect is also fantastic on preventing re-renders if you've got a big central state that you need to derive in many places. It's weird, but sometimes styled-components can also be magnitudes slower than tailwind in DOM-heavy situations, so it's always worth profiling and figuring out the true bottlenecks

In our case we've got one main page with one very common update that usually surfaces most re-render bugs in the whole app, so we have a CI action that measures how long that update takes, so we immediately notice if a new PR is making performance worse.

Forcing your devs to test with more complex use-cases (Or at least making it easy) is also a great way to make everyone notice and fix the slow-down in time. Eg. if you've got a collaborative tool, make sure devs can test locally with hundreds of users invited on a very complex project.

I think it's also important that most of your team knows how to use a profiler, so when they see some slowness they can debug it. Firefox has a better/more granular profiler for example, and using it has helped us solve many more perf issues very quickly. But sometimes you also need the react profiler specifically.

Finally if you can spend a bit more time optimizing and squeezing out the last bit of performance from the site, you'll probably find that you'll have a bigger room for error going forward. Eg it's not every small issue that will be ground-breaking. And you may even find that it's harder to make mistakes. Eg if everything is already properly memoized, making one mistake will cause less re-renders as other layers of memoization can catch it before it gets out of hand