To be honest I completely disagree with most of what you've put. That's not to say that I think Go's templates are an amazing "must use" feature, but rather that the problem points you've raised are really more to do with learning the tooling than shortcomings of tools themselves (unless you want to argue that web development - CSS, JS, HTML etc - on the whole is a backwards approach to writing applications, in which case I whole heartedly agree. But that's an argument for a different thread hehe)
1/ You can have templates defined within the executable if you wanted. But you can also trivially find out the working directory of the Go executable if you still wanted to work with absolute paths without having to hardcode the location of the Go binary
2/ I've not tried to look, but often you'll fine that larger projects will eventually fall into NIH (not invented here) syndrome where a standard package fits 90% of their criteria but they have the developer man power to write a competing solution that fits 100% of their criteria. Templating is a pretty easy problem to solve in that regard.
3/ That depends on whether you want to cache the precompiled template or the compiled template. Without knowing your code it would be hard to accurately advise. However if the abundant documentation isn't helping you then write two versions of the code, one precompiled and one after compilation; then unit test each - if passing the compiled template around doesn't introduce caching bugs then go with that. However generally I'd recommend passing the precompiled template around for 99% of typical use cases.
4/ I find that a weird complaint. If you understand front end development well enough then you shouldn't have any issues keeping the code clean. If you don't, then perhaps you're trying to run before you can walk? In any case, I wouldn't rely on linters to clean your code. Sure they are a fantastic productivity tool; but if you become too dependent on them then it will hamper your development skills in the long run.
5/ the first part of your statement is really a matter of learning front end development. Generally you should never inline CSS nor JS unless under specific use cases. But general web development should nearly always have the CSS and JS separate from the HTML document. The last part of your statement is a reiteration of question 3.
> I can't really tell if there are any speed gains to using templates, so it feels like a lot of sacrifices for no obvious gain. I do think templates would be godlike if they featured vue-like structure with "template/script/style" syntax, and was easily minified and compiled into the binary. But I guess I can keep dreaming about the last part :)
You're comparing front end development frameworks with back end frameworks, so they're obviously going to differ. Plus you can easily minify templates and embed them into the Go binary (the example in the article you're commenting on does just the latter).
-----
With the greatest of respect to yourself, I think the issues you are having here isn't so much with the design of Go's templates but more with your experience with Go and front end web development. A lot of the problems you've identified become pretty self explanatory once you spend a few years writing code. However that's not to say you're asking "dumb" questions - they're definitely problem pains with web development that all of us had to work through. I guess in this regard Go's documentation might be a little lacking as I've found it typically focuses on the expectation of the developers prior expertise. Stick with it though, you're asking the right questions so it will all make sense soon enough. And don't be afraid to make mistakes while experimenting :)