My perspective is that of someone who usually has to make choices for software projects that are going to exist for a while and that will have lots of developers on them. If you manage software projects you will tend to always feel some pressure from developers who want to use marginal technology. Developers whose only perspective is what is right in front of their nose will tend to have different perspectives from people who have to think about "how do we maintain this 5-10-15 years from now?".
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.