People like to act like you just open a profiler and see actionable data every time, but that's under ideal circumstances. In a busy application, you're more likely getting nickel and dimed by more subtle things. And your flame graphs stacked with React/library internals that don't point to a single problem in your code. And you have to have the skills to recognize and verify small performance gains when you do have them.
If that stuff doesn't line up, then you're stuck with little more than superstition and hoping other people's solutions generalize over your problems.
"this is nice, but it isn't JavaScript, not yet anyway, so now we need to talk about how TC39 works and evaluate our draft stage risk tolerance"
I don't see that particular feature a risky to use, it's so wide spread in Babel / TypeScript that if it were ever overturned there could be a automatic transpiling solution to fix all that.