First and foremost, the author advocates for organising documents in a much flatter DOM tree. In this style all major page elements sit at the same hierarchical level, so there is no "mess of nested elements", the is no need for visual indication of hierarchy if there is no hierarchy to begin with.

I think that is a very compelling format for a text-first web page, like a blog post or news article. Of course it is a coding style not well suited for complex web apps with deep hierarchy.

In a tree you have branches off branches off branches etc.

You can’t orient yourself - you can’t tell where you are - unless you count the branches. And indenting makes that visible.

In the examples for TFA, you can tell your location from the names of the elements. Eg <td> is enough for you to know you’re probably inside a tr inside a table.

And that is the more common case than the general tree example.

But a method of describing html does have to answer the question of how it represents arbitrarily deep nesting. But I like the answers it’s given for the more common case of structures that are not arbitrarily deep.

The problem is that HTML has multiple uses. The author is describing the case of authoring content, with HTML used as a markup language. However a lot of websites and web applications use HTML more like a layout and templating engine for a GUI framework.

Only if the formatter is unaware of HTML. If it can't handle automatically closing <p> tags, then it's unaware and is trying to treat HTML like XML.

Or, to put another way, HTML != DOM, even though HTML can be rendered into a DOM.