First, the author of the article is Ryan Florence. He's a very well-known name in the React community, as he's co-author of React-Router, and co-owner of the React Training company.I appreciate that. However, there are plenty of genuine experts with low profiles, and unfortunately there are also plenty of high-profile trainers who have relatively little recent, deep experience as practitioners because they're constantly jumping from one context to another. Whenever possible, I prefer to consider writing objectively on its merits, rather than by who wrote it.
Just to be clear on one point, though, when I wrote "his own limited experience", that wasn't intended as any sort of insult or criticism, merely a statement of fact. It's a huge industry, and no-one can possibly know everything about how a library like React is being used or what experience has been collected by the numerous other people using it in different ways. Authors who write as if they do are a pet peeve of mine, particularly when, as in this case, they do so in a way that implies others who might disagree are automatically wrong.
It _is_ trying to say that that has become a blanket concern that people blindly repeat, no matter what the actual performance concerns are for a given component, and that some of the possible origins for that concern are likely no longer an issue with modern JS engines.
I agree that we should be careful about dogma, and we should be careful about relying on data or assumptions that are no longer relevant. These are perennial issues in tech fields, and caution is wise.
However, I think it's also wise to remember that not everyone is running the latest and greatest browsers and JS engines. For example, there are many web sites used in businesses where desktops will be locked to a specific and possibly older browser to ensure compatibility with their other in-house tools.
I've seen learners who are still trying to grasp the basics of React being told "oh, you should never use an arrow function in `render()`, that's slow". Even if that's true, that's also not the advice the learner needs at that time.
There is a more general point about teaching here, I think. My own experience from teaching a variety of fields over the years is that showing a simplified version of something is often helpful for beginners, but showing an inaccurate, misleading or exaggerated version of something can be dangerous.
That same beginner who learns to casually build new functions by default in this sort of situation is, almost by definition, not going to know enough to realise when doing so in a more demanding context might be dangerous, and there is no guarantee that anything or anyone will arrive at a more suitable point in their development later to broaden their understanding or warn them about any implicit assumptions behind what they learned before.
In this case, clearly I disagree with the author about there not being any data to support concerns about passing new functions as props in this way, and I also think he exaggerates the cost of avoiding that problem by using any of the common alternative idioms in such cases. So I don't think it actually is a very good idea to teach beginners that this is OK and write off the concerns about performance so definitively as some sort of mere historical point that no longer applies.
To specifically answer your last aspect: Let's say you've got a child component that implements a click handler like this: [...] In that example, `this.props.doStuff` isn't actually affecting rendering.
OK, fair enough, that's a valid case. Ironically, it's also one I should have allowed for in what I wrote before: I seem to have inadvertently edited out a paragraph from an earlier comment about the alternative strategies we use, but one of the specific examples I gave was having props include both a callback function without pre-bound parameters and separately an ID value. If you can accept the arguably undesirable dependency of having the component's own event handling code always call the callback function with the ID as its parameter, thus allowing both the callback function and the ID to remain strictly equal in props from one render to the next if nothing is actually changing, then you wind up with code essentially the same as your handleClick example, and yes, if you're careful then you could skip checks on callback functions in shouldComponentUpdate that were only used in that way.