I think the author is probably aligning with "is" rather than "ought". So a language made this list if it IS being used as a configuration format, regardless of whether it OUGHT to be used as one.
Which is a way of deciding that makes sense given that I think the purpose of this article is "use my language instead". Getting lost in the weeds about each language's original design intent would bloat the article without meaningfully contributing to their thesis.
Given that it's an essential/definitional issue, I would have preferred that the author at least showed awareness of the differences between languages intended for marking up text and languages intended to represent data in a structured way.
Back when XML was first being developed, I was really anticipating having a standardized, easier-to-implement successor to SGML (which was hampered by its complexity and by the cost of the ISO standard) in the text markup space. It was that disappointing it ended up filling the vacuum in the space of serialized representations for for structured data, then getting rejected when it wasn't quite as suitable for that as alternatives such as JSON.
Me too, I still think it's cool. But while indeed easier-to-implement compared to SGML, it could have been yet a bit simpler. :) I once attempted to write a conforming parser, I remember it being a _lot_ of work to even determine well-formedness.
Ah, I was perhaps a bit unclear – I didn't mean to comment on whether certain languages made the list or not, I enjoyed the thorough walkthrough of languages being used for configuration.
I was more commenting on comments such as this one under Pkl:
> This is not a markup language. This is a full-blown programming language.
And under Nickel:
> Nice programming language. Not a markup language.
It's like he's saying "we should use markup languages for configuration, not programming languages", which I don't think he means.