It looks unnecessary. The syntax is ugly and by looking at the examples I can’t say what problem it is supposed to solve.
It's like HTML but less verbose, less errors prone (<p>foo<b>bar</p></b> is impossible to write), and basically the formatter is part of the language. What is there not to like?
As for adding a layer to what devs needs to learn - that's why I don't generally use this at work. In those situations you often need to pick the most common tools and not the best tools.
JSX?
It was dog slow and it had some really stupid api you had to use if you needed to handle nesting that you couldn’t determine until runtime (on account of the no closing tags—use case: rendering a tree of data in a streaming-records sort of situation, not exactly a super-rare need).
There was a faster implementation, several times faster… but it achieved that in no small part by ditching the bits of the api that allowed you to manipulate nesting, so I couldn’t use it.
That project made me hate crap like this. HTML isn’t scary, hard, or even (in a halfway modern editor) slow to write, FFS. I’ll never ever pick this sort of templating language when it’s my choice.
Then there's all the other syntax that needs to be crammed in to make the language do what you want. HTML doesn't have lots of special characters strewn about the place that have meaning, but Haml does. You now have to understand HTML, Haml and how Haml is turned into HTML. That's a lot more complexity than sticking close to HTML.
It seems like a lot of unnecessary work to use Haml (and impose it on other people through code) if your reasons for using Haml are purely superficial.
"Haml accelerates and simplifies template creation" https://haml.info/
If you'd rather write raw HTML, keeping track of closing tags etc, then don't use HAML. No need to bash it because you personally feel it is ugly or unnecessary. FWIW I personally feel the exact opposite.
Haml is marginal. Haml for Go even more so. That's simply observable fact. Most Go developers will not have heard about it even though it has been around since 2006. Which doesn't make it an obvious candidate. If you choose it over the standard library templating language you will have made a choice that means almost every developer involved will have to learn Haml rather than use what they already know. And possibly just for that one project that uses Haml in Go.
Every technology you introduce into a project places a further burden on anyone who has to understand the code. If you choose marginal technologies the chance of developers being proficient in them goes down sharply. The chance that you have to replace them later also goes up. That can have considerable cost and take a long time.
Using Haml in Go projects is a big ask, which means you have to be able to rationally argue why developers should leave the beaten track. If we start by looking at the Haml implementations for Go, I'd say there is no reason to consider it now. There are a handful of libraries, but none of them seem to have that much of a well organized dev team and a community around them. It seems unlikely to displace existing solutions.
This means that if you choose it and weave it deeply into how your application works, you might end up having to maintain (one of) those libraries yourself. Exposing your project to that kind of risk is unprofessional.
And note that this is before we even consider the language itself.
And by the way, accusing other people of bashing the language simply because they express an opinion you don't agree with isn't very productive. Yes, I have read the documentation - and yes, I still don't see what problem this is supposed to solve. We already have lots of languages for expressing things that will render to HTML. I don't see how Haml is significantly better than other ways of doing that currently in more widespread use.