As per your development process, if you use htmx you can serve the template files from disk. Then all you need to do is edit the html templates which your backend reads in. No need to rebuild your golang application. For some changes you wouldn't have to reload the page just click the interaction to get the html fragment from the server.
You would need to rebuild your go application if you are changing parameters input into the template but that is conceptually the same as a client side template needing an API change. This also requires a rebuild.
There are a few actions that are exclusively client side, like opening a context menu, that I'd use a "sprinkle of JavaScript". There is a recently added htmx attribute "hx-on" that might work well for those cases.
I'd also not discount doing a round trip for some of that. Those GET requests can be very fast and will be cached. Given the poor performance of many SPA's a quick, cache-able GET request might look pretty good.
Also, even if serve returns HTML as list of files instead of JSON, HTML can be seen as a flexible data format in itself that has few added advantages.
JSON is superfluous when the only consumer is the browser based UI and no third party is going to have that response ever.
Not going to debate you line by line, but HTMX doesn't prevent you from using client-side JS, for example to create your right-click context menus.
To use a concrete example from another app I built: it's a web-based file browser for S3 (think Norton Commander for S3 on the web).
You enter S3 creds and my backend code gets a list of files and sends to the client as JSON. I generate UI (HTML) from that JSON.
Could the backend generate that HTML? Not really, because it's not just a static list.
It's a sophisticated file browser. The user can double-click to "enter" a directory, navigate the list of files with a keyboard, right click to get context menu with options to delete, rename files etc.
My UI (HTML) needs to be mutated and it's not even possible to offload those kinds of things to the backend because they are driven by the state in the client (mouse movements, keyboard events, scroll events etc.).
That's the capability part: a lot of things can only be done in the client.
As to productivity: even if the needs are not as sophisticated, my productivity in Svelte is off the charts.
Let's say you just generate static HTML for the list of files.
Generating HTML is a very iterative process: you start with the basic structure, you try it and then you tweak the CSS to make it look better.
Since my backends are in Go, changing a single line of Go code requires killing the server, rebuilding it and restarting it and since I lost all the state, re-doing all the steps needed to get to a page I'm working on.
My iteration loop per single change is minutes and very annoying.
With Svelte I have an amazing HTML templating language and with HMR (Hot Module Reload) I often don't even have to refresh the page: I change my .svelte file to, say, add a class to <td> element, I save it in Visual Studio Code and the page get magically refreshed with new visuals, without loosing the state.
My iteration loop is basically nothing.
Over many iterations, that all adds up.