I've been using React as my primary platform for 3 years now and I'd be interested in novel React criticism.
I believe the most important thing when developing software is managing state. The best cross-language technique I know for reducing state is to prefer functional approaches, lock down mutability wherever possible, and prefer persistent datastructures. These techniques cause problems for truly high performance code (HAMT-like datastructures have pointer contention at the head) but very little of the code I write is that performance sensitive.
From the UI side, I believe the reactive programming model has won out and I'm unaware of any medium to large javascript frameworks that don't have some sort of change detection/propagation system. Polymer is the most dom manipulation oriented current gen framework I know about and it still makes substantial use of observables and bound properties.
Put together, I currently believe that the virtual dom diffing approach on persistent datastructures is the best general purpose starting point for building a user interface. The biggest arguments against the approach I've heard are that it's memory inefficient since the entire output virtual DOM has to be retained for diffing and that the diffing process itself is less efficient than direct change propagation using observables. While both valid complaints, I have not found them useful complaints.
For memory, the target market for the apps I've written has yet to include mobile devices that are memory constrained to the point that virtual DOM size is a significant factor and if they did, I'd be inclined to try something like incremental dom before abandoning the pattern.
For performance, the combination persistent datastructures guiding the diff substantially reduces the amount of diffing overhead. I've been able to hit 60 fps on a randomly-update 10k DOM node stress test using Inferno and a custom HAMT implementation on a 2012 Macbook Air and ~25 fps on my 2nd generation Moto X. I consider this good enough but I can see how people who are more focused on mobile and in particular emerging mobile markets would have different opinions.
My counter to these arguments is that I find the performance characteristics of the virtual DOM easy to reason about and performance being primarily driven by the output size has allowed me to take input datasets that I would not have even considered on observable systems. An example: I put together a calendar that was supposed to be a temporary prototype, wound up getting put into production (semi-predictably), and we had the events input grow to 9MB of gzipped JSON (two orders of magnitude more than I expected) before it got replaced. Load time was terrible but once it was up, latency for all actions was ~30ms.
As for React itself, I find it acceptable. Its artificial event system made more sense when it was made but I think it's more overhead than value these days. I've never liked setState and never used it in a production app. The main reason to stick with it over a second-gen vdom library like Inferno is network effects. I tend to not use a lot of third party code so I expect to switch to an alternative vdom at some point in the not too distant future.