Yes. There are a few conserns. Regarding @misan's points. You can write accessible react and you can add the same structure and attributes since in the end it does render HTML to the DOM.
As to SEO, it's not really much of a hindrance. I've worked in a couple larger sites and hosting environments and 5-7 years ago, Google was only a few days behind in computed detection vs. static rendering and can only assume it's much closer to actual today. Bing also does computed renders for content. Beyond this, SEO doesn't actually help much these days compared to general marketing efforts.
You can server-render and cache React, there are lots of tools for this from Next.js and other frameworks. Walmart has written and released a lot of tooling in this space. Again, I don't think it's that worth it most of the time, but ymmv here.
Where I would concentrate is using webpack's analyze options to pay close attention to your gzipped payload size. Ideally you want to stay under or around 500k. Which is not hard, I'm working on a pretty complex web application and it's around that with React and Material-UI libraries taking up the bulk and about 25% actual application code beyond that. For comparison, Grubhub is about 442k for their initial (not logged in) JS payload and over 2MB on a fresh load logged in (Angular I believe).
If you're more content driven (blog, resume, etc) I would tend to favor a static content generator such as gatsby mentioned by @misan.
Do you care about seo and accessibility and performance? Then use gatsby with netlify. It is an easy server side rendering framework around react