I've been thinking about this sort of thing a lot recently in terms of our heavy use of Troposphere[1] which is a Python abstraction over AWS CloudFormation and how much better that abstraction is than just writing HTML (in the case of this library) or JSON/YAML (in the case of CloudFormation) directly.
Ultimately, for me, it comes down to what makes sometimes complicated declarative code easier to reason about, read and understand - it's a simple as that.
Some things are just _easier_ to write when you've got the power of a Turing-complete language with a decent standard library behind you; if for example you want to dump out a sorted list and then be able to easily update it later, or print a list of links alongside a hash of the contents of their targets.
I guess if you're building a simple website, anything like this tool could be overkill and you'd risk spending more time setting things up - and maintaining it in the future - than you'd be likely to save by using the tool in the first place. But for more complicated output having more tools to use lets you be arguably more declarative; you just change the input data to generate the desired output. You describe and allow automation of the _transition_ from input data to the desired end point.
I could definitely see how libraries like this would be tremendously useful for generating HTML. As it happens for our AWS infrastructure generation we enforce the use of Troposphere everywhere, because in that case the cost of setting up and maintaining it is essentially just copy-pasting an existing Makefile.
I guess it is mostly the subjective comfortableness of python (and the capacity of throwing prototypes for a team who has only python skills).
In my experience all these frameworks end up lacking at some point and becoming leaky abstractions sooner than later. I wish they would work because all the front end technologies require lots of training and skill in order to produce a production ready UI.
