Ask Questions and Find Answers

Without being too much in the Frontend world myself: Isn't the portlet just a generic portlet that can be configured with any react app? As Liferay, in its root, combines different portlets to a common UI anyway, this doesn't seem too bad, especially when there's a generic portlet for all react apps. Yes, it could be in Fragments as well, but wouldn't that mix apps and content?
Note: this is neither positive nor negative, just an alternative way to look at it. I'm typically distancing myself from the frontend as much as I can - others are quicker to produce nice results.
This is also nitpicking of the "best solution" question, where I can't resist asking back: "Best for what?" In the end, the various solutions won't be too far away from each other.

Well, I am not sure about that.  Portlets bring a nice set of features with them and it is a pretty sane approach to bundle a new component into a portlet, to take advantage of those features. On the other hand, from a developers point of view, you care about getting your component (be it React, Angular, vue, ...) into Liferay *without* the need to know a lot about it.
Honestly speaking, do you really care that a portlet provides your React module to Liferay instead of a "ReactComponentProvider" (a thing, I made up just now)?
That said, I have used a different approach before. We have our own webpack bundler, you can find a few things about it here.
https://liferay.dev/blogs/-/blogs/developing-javascript-frontends-with-webpack
But I am actually thinking about moving into the Liferay direction, I hear the fragment builder will support npm in future versions too. The big advantage of webpack is hot reload, but the bundler/loader of Liferay allows me to create microfrontends. And that's also very neat.

yeah, up to the frontend app to construct the so-called 'page' (view) built including using 'stuff' it might get through the api ; I think that is to be expected/preferred in decoupled frontend from backend