Nothing is perfect. If a framework isn't right for a project, then it's better for everyone if that framework isn't used. To help you figure out if React Native for web will be a good fit we've assembled this anti-pitch!
Expo web is still in beta
Starting in SDK 33. You may notice a pattern in the following points 😉 We've identified as many of RNWeb's weak-spots as we could and hope to fix them all with Expo. Until Expo web is stable you should consider all of these points as unresolved.
Not enough universal libraries
This is a big problem when using React Native for web, but now that the Expo modules have web support it isn't any longer. You can find a list of all the supported modules here native.directory
Webpack is time-consuming and difficult
Even the most basic app requires transpiling and tree-shaking. Expo CLI provides a default webpack config (@expo/webpack-config) which is akin to Create React App and hides a lot of the complexity away until you need to make customizations. But if you don't like Expo or Webpack this could become problematic. Also worth noting that the majority of the remaining pain points bubble down to Webpack and Babel.
Tree-Shaking is too fragile
Historically it's been very easy to break all of the tree-shaking in React Native for web, which would cause your bundle to be huge. Importing any third-party library almost guaranteed that you were going to be importing unsupported modules. This has since become a lot more bullet proof but it's still very finicky with packages outside the react-native-web or Expo ecosystem. @expo/webpack-config has built in support for webpack-bundle-analyzer but just be wary of accidental bloat.
You can use react-native-web with Razzle but Expo support is not something that is on the horizon. Most of the native functionality that people will expect in a native app won't cross-over to SSR at all (things like camera, or location). Since Google announced that Google Bot will use ES modules, SEO in React Native web apps will work as expected without SSR.