The assertions about the DOM are long on hyperbole but rely on e.g. benchmarks from a decade ago and broad hyperbole like:

“This was cumbersome. This was limiting. You could not prototype easily and quickly. You could not easily escape the limitations of UI libraries. etc. etc. etc.”

It would have been far more interesting to look at whether the broadest claims were even true, or why people ran into problems using various libraries. Every time I've done a test, React is significantly slower than using standard JavaScript + DOM but that's the wrong question to ask when you really care about whether it's a) fast enough and b) helping you write code faster, reducing maintenance or sharing costs, etc.

All I got from this is that using React makes life easier than calling the DOM APIs directly every time, which is technically true but doesn't say anything about e.g. how WebComponents compare when using abstraction following the best practices of software developers since something like the 1950s.

The “easy-peasy” example is:

    ['Hello', 'world'].map((text) => {
        return <p><span>{text}</span></p>
    })

The alternative given is:

    ['Hello', 'world'].forEach(text => {
    	const p = document.createElement('p')
    	const span = document.createElement('span')
    	span.textContent(text)
    	p.appendChild(span)
	
    	MyComponent.appendChild(p)
    })

Since the first example requires 140KB of React code plus a ton of setup code to get to that it's either careless or dishonest to compare the two without acknowledging the possibility of using a helper function or two to simplify the second one, as JavaScript developers have been doing routinely for multiple decades.

Again, not a slam on React, just this kind of unhelpful advocacy. It'd be a lot more interesting to compare real examples with multiple libraries and talk about how the different choices impact debugging, performance, isolation, etc.