A HTMX-y app will typically be a fetch-heavy app. Think TODO list, where each time you add a todo, you want that persisted on the server anyway. Yes you are sending more down the wire. I doubt rendering a partial HTML template is that much more work than formatting JSON but there is more crap to send down the line for sure.
Where the application is doing lots of micro-level stuff, like maybe you are drawing on a canvas and occasionally sending a payload of updates to a server, I think then HTMX would be much slower and clunkier, and that is when you dust off your React.
Render is a different thing in both places. Server Renders is ... formatting a sequence of bytes. Hopefully your templating engine is optimized and it is a low cost operation. Rendering on the client is obviously more involved as it requires actual rendering on the screen using the graphics drivers.
On the other side of the scale, React has overheads like a virtual dom.
It is a complicated question as to what is most performant, who bares that cost, and so on.
I'm not talking about most performant. Neither HTMX nor React has a performance issue.
The issue is overhead and complexity for the developer, and maybe, server costs.
React comes out ahead in server costs, since doing work on the client is very cheap (provided there isn't a performance issue that turns users off, which there isn't).
And in terms of dev time, it depends, but you can't say "look, with HTMX you can avoid code" because you still do need to write code, but now it's in the server.
Where the application is doing lots of micro-level stuff, like maybe you are drawing on a canvas and occasionally sending a payload of updates to a server, I think then HTMX would be much slower and clunkier, and that is when you dust off your React.