Not a full stop; SSR means they could render before client-side JS.
The example is a bit too simple to make the author's point IMO. A web component that handles changes to state would be a better comparison, and make for a better argument.
Hydration solutions exist but are usually worse and come with surprising tradeoffs and harm composabilitiy.
Arguably they might be less optimisable than regular web frameworks, as they make it difficult to coordinate between different components on the page.
Good load order and only loading in the content and JS above the fold initially helps a ton.
JS frameworks are huge and I am still saddened that proper tree shaking and optimization got left by the way side in how the modern web has evolved. I worked with google closure in advanced modes and the closure components for a few years and the compiler was absolutely astounding (and the components designed with the compiler in mind) in code splitting, tree shaking and minimization.
You want to have the tags and content appear in the web component (not rendered by JS) which makes it easily and immediately available to crawlers.