Real life is not code golf. We do not build things entirely for ourselves. We build things for our employers, for our co-workers, for our family members and for our friends. We build to create value for someone and value is not a one-to-one correlation with the weight of a site in KB.
If I can make it easier for me and anyone working with my site in the future by sacrificing 50-150 KB then I will take that deal any day of the week. That is what abstractions are for. That is why we do not work in byte-code. We pay for convenience in clock-cycles and disk space.
Arguably, using React where a static HTML with maybe a little bit of vanilla JS would do, is code golf.
HTML and CSS are not bytecode. They're high-level abstractions, hiding a very complex renderer underneath. Sometimes you need to build another tower of abstractions when this doesn't suffice - like when you're trying to build an application with complex GUI in the browser and you need an adapter between DOM and a more suitable GUI pattern. But displaying text and images communicating a message is not one of those cases.
We do not rebuild the tower of abstractions for every site that uses them. I do not personally implement React from scratch when I use it for any of my sites. I get all of the benefits for none of the effort. You do not seem to acknowledge factors other than straight up performance, as is evident by what you are picking and choosing from my comments, so obviously it is not attractive to you.
Yes, instant page navigation without flickering is better than the alternative - instant being what you get from reloading a static HTML page, alternative being React.
Seriously, fetching, parsing and displaying a tiny bit of HTML is fast. As fast or faster than the React virtual DOM shenanigans, once you account for the computational load the framework adds on top of your simple page.