Okay, I'll bite once more:
JS minification isn't the same thing as HTML minification, by grouping similar patterns you increase repetition and get higher compression ratios. That and you know more about the context, like for example strings are case-insensitive and you can normalize them, JS minification cannot do that and by combining the types it will be less effective.
You are (hopefully) minifying the precompiled output that's all javascript. JavaScript minimizers are really good at minimizing javascript. You aren't combining types. Minimizers are context aware. They can group similar patterns. Compression rates are rather high.
It is embedded XML. What it becomes in the end is not important, but rather why this representational form was chosen (otherwise why use anything but JS). The data was easier to represent in XML than JS functions because it was doing something JS isn't good at but XML is (semantically structured data). But that whole problem is why you'd split it anyway keeping good separation between static (but structured and semantic) presentational "views" and logical dynamic MVC-conceptual "views".
Again, this is separation of concerns fallacy I have repeated multiple times now. Go back, rethink, come back.
Also, that streaming wasn't quite what I was thinking, in fact I'm not sure why you'd want that at all. If you are building server-side, and shoving into HTML, unless it was a static page you'd just wind up touching it again with React (or more strangely some other DOM manipulation means) so you might as well just serve the JSX view and let the client handle it. I was more thinking taking the raw HTML and piping it over a fetch stream, maybe even in the near future using a DOM worker to stamp it out.
Go back, read what the description of react-dom-stream says and come back. Why would you want it? For great benefits of user getting the first bytes instantly making the the first page view near instant. If you are creating static pages, that's it. Or you can just serve the first page and let clientside React handle the rest. For the last paragraph, you can already do that. See what ReadableStream renderToStaticMarkup does.
The best reason I'd see to use JSX is for smaller projects, especially prototyping. At that point such gains I describe are insignificant and the organization cost is small. But at the same time, introducing a transpiler (and thus a build and all it's dependencies) is quite a huge dependency cost that will likely lock you in to using it forever. In a larger project where you're going to have much of that already you probably do have enough templates and a large enough surface to refactor that those are things to more seriously consider.
If I'd stab myself everytime I hear the "smaller projects, for prototyping" fallacy I wouldn't have places to stab myself left. Best reason to use JSX is that
it's a really good fucking expressive way to build reusable components. If you are doing "large projects" you most likely have a build step, because why the crap wouldn't you have? Obviously you can go all vanilla and do all the things by hand, but good luck with that. You are as locked into it as you would be on
anything else, be it your homegrown templates, HTML5 templates, anything.
If you really want to talk separation of concerns idealism I think the entire web stack is poorly designed. They eventually got style (css) and logic (inline js/handlers) out of HTML (well until angular missed the memo and put it back in) but HTML still has way too many functions: data (text), layout, accessibility (aria) and data semantics (tags). If I had my way you'd have a layer for data (JSON), a layer for data semantics (HTML), a layer for accessibility semantics, a layer for layout (pulled from both CSS and HTML), a layer for style (CSS) and a layer for logic (JS). That's my purist dream.
I know you think you want that, but most likely in the end you don't. Why? Because coupling them together is a pain in the fucking ass. You'll spend hours and hours and hours of busting out code that does nothing but ensures that your 9 layers of hell can produce a single working example. I have worked on huge projects that do exactly that and I would never want to go back, but there's no reason why you couldn't do it with any modern technologies. Even with React, or Angular,, or Ember or Vanilla everything.
I know this sounds like a rant, but really, before you make such statements you should go back, do a small TO-DO list example, really think what you are doing and what you could be doing differently, maybe watch this small getting started on Redux if you are worried about separating your data in React (
https://egghead.io/series/getting-started-with-redux) to get a handle of the Flux pattern, see if you can see the benefits of using JSX in general.
(Once again note that you can use JSX without React and React without JSX. The reason I am talking about both of those together above is because React is a really good way to build reusable components and JSX is a really good way to represent the markup for them, which is why it's the defacto way of building the markup for React components)