> 1. There is no adherence to the living standard
Do you mean the HTML living standard? Why would a javascript library be concerned with the HTML standard? What do you mean with this? The HTML output from React certainly complies with the living standard, and it doesn't even have any artifacts now that react-ids have been removed.
If you meant the javascript rolling standards, React pioneered the use of many ES2015 features.
> 2. Web components are meant for this exact purpose
Web components are meant for encapsulation, a problem that React handles fairly poorly. Meanwhile, React's alleged purpose is to handle developing large applications, a problem that web components do not really address.
> 3. The added complexity and burden on the browser runtime will only create headaches as the application begins to scale.
Practically every abstraction adds complexity and "burden" on the runtime - even Web Components! This is an assertion without evidence. There's a contention line between performance and development time that, for web applications, is usually skewed heavily towards the development side. You need to deliver your web applications in a short time frame, and also continually update them. These are the things React alleges it excels at, while also delivering acceptable performance.
> 4. There is no clean separation of concerns.
React has three clearly separated parts, component definitions, VDOM rendering and reconciliation. Which concerns aren't separated?
> 5. Writing HTML in js files is an anti-pattern.
React discourages writing HTML in js files. The standard method of using React does not involve writing HTML, React renders that for you.
> 6. The browser runtime, CSS and DOM obviate what React is trying to accomplish, especially with web components being added to the living standard.
This is just word salad. How does the browser runtime help with developing large applications?
How does CSS? Just look at all the CSS frameworks trying to wrangle the complexity of managing CSS in a large application - from CSS parsers like less and sass to naming styles like BEM, CSS modules, and so on.
The DOM isn't concerned with writing large applications at all, however directly manipulating it is usually a minefield thanks to its API and forced re-renders. Pretty much every JS framework has run away from the DOM.
Web Components don't really tackle the problems building a large application.
> 7. Browser networking, workers and server-side events are much more powerful ways to scale complexity.
I don't know how any of these things help with complexity. They're performance optimizations.
> 8. CSS3 is not hard to understand.
This is not an argument against React, since React components use CSS..
> 9. There is no way to bypass the browser's rendering engine.
Thus, we should never write libraries and frameworks for rendering? What is this even an argument for?
> 10. The business scenarios for our software product did not align with the use of React after a very thorough ATAM.
That's fine, but that's a consideration you make for yourself. It doesn't make React "quite possibly the worst anti-pattern". This is the first reasonable argument you've made.
> 11. Much better technologies exist that do not cross-cut concerns the way React does. Aurelia is what I ultimately recommended because it did not violate points 1-10.
This is possible, I haven't used Aurelia to comment.
React is very pragmatic for me. I've been moving towards data-driven UI rendering ever since I started web development. The components have good lifecycle hooks, unlike angular 1's directives. The VDOM rendering frees me from touching the DOM(a huge plus for me), and I've never had to wrestle with its edge cases(don't really do a lot of animation). The diffing engine makes it absolutely fast enough for any app I've written. The combined coding style(don't store state in the DOM, render the UI from state, take props instead of locating data via global services) is a great fit, I've already tried to enforce all these for my team manually. The documentation is top-notch, there's tutorials for everything. The tooling for it is just great. The debug story just makes me happy. Debugging React apps is a breeze compared to any other app I've had to debug. This is probably the biggest selling point for me. I am willing to go through quite a bit more pain than React causes to get this kind of debugging.
React for me has some fundamental problems, like its small surface area(only handling the view), which means it doesn't solve all my problems. The things I use it for though, I'm really content with.