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?
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.
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.
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?