> ReactDOM.render is only different to these examples in terms of scale
I think you're confusing longitudinal vs latitudinal comparisons (see point about direct competitors). Sorting is not a competitor to React, or even in a similar class of tools.
I did mention equivalents to ReactDOM.render in various frameworks. Those equivalents also differ in scale in the exact same way as React does to sorting, and yet we're clearly in framework territory when we talk about them. One substantial difference I addressed is that React is inextricably integrated to its internal state and re-rendering mechanisms even if you only use ReactDOM.render; calling setState will always take over control for managing batch updates (not calling it is beside the point; it's always available). This is objectively more "frameworky" than, for example, Mithril's `m.render`, which acts like a true library in this case (and yet, it's still a framework).
> I have migrated more than one substantial web UI
I'm not sure what this has to do with the point you quoted. We've established w/ the lodash example that it is possible to "permeate" the codebase w/ a library, but that doing so is not an intended use case for a project that is a library, and conversely a project that is designed to dominate a complex control flow orchestration between user code and itself throughout a significant portion of scope for an app is a framework characteristic (and React presents that characteristic)
> had a clean separation of concerns along the lines of MV
Here, it appears you're conflating framework-ness with a specific scope size (roughly the size of MVC); this is inaccurate. Consider that Ionic is a framework despite being largely a "only V". Consider that Jest is a framework, despite having no concept of M/V/C whatsoever. Entity is only "M" but also a framework. But what they all have in common is they are organizationally opinionated within their scope of operation (this is what alluded to when I mentioned spaghetti code).
> If your argument is that React is a framework because those claims are defining properties
They are not defining properties, not exclusive to frameworks, possibly not even universal, and certainly not an exhaustive list of arguments. What I'm saying is that these are arguments used to support the idea that React shares an overall strong semblance to frameworks (even if the imprecise examples can be nitpicked to whatever extent). "If it quacks like a duck" and all that.
If we were to zoom out a bit, the entire reason why this whole framework-vs-library thing is even a thing stems from objections that the "just a library" tagline is often mindlessly parroted as a soundbite to support the idea that React is not "bloated". But ironically, if you scroll around this thread, you'll see that this correlation has lost its edge on two fronts: a) people now complain about fragmentation in the React world caused precisely by its lack of opinions in various areas of web development and b) many of the frameworks I mentioned are less "bloated" than React (because they don't support multiple ways of doing components, because they offer equivalent functionality in less bytes, or because apps written in them require less boilerplate for things like state management, for example).