Firts of all React is not a full stack web framework.
It's just a "view" part of Model View Whatever concept.
Thus first and last cons of this reading is not related to react.
One should use some data flow manipulation means in conjunction with react when building big apps.
A good example is Redux based on FB Flux approach.
There a "service" diapatch function is available for every component and you can avoid cluttering components with passing callbacks.
Async logic can be easily implemented using redux-saga with them utilizing es6 generators.
It allows to describe the flow of a certain action as synchronized one: do some preparation, send request, wait on success, update your state, do smething else, quit.
Problems with class name and for attrs in JSX is not a real issue I would say.
While as flow typing is still indeed immature we use FB flow type to cover whole app.
And inline styling I would say is bad approach anyway because we ptefer to store and load style to/from CDN via CSS classes.
As for React's Dom comparing algorithm we do experience some problems.
You always have to keep in mind how many rendering cycles you would trigger performing some data manipulation.
To sum up:
Two of four cons of the article are irrelevant to React because data manipulation infrastructure is out of the React's scope.
JSX templates are a good fit even for big apps.
And React's vertual DOM algoriths should be improved indeed.