I interpret it as any enclosed data, be that in
*** , or
# . Is that interpretation correct?
Not quite. Emphasized text is enclosed in
*s but is an inline element, not a block element. Perhaps you missed that blocks and inlines are mutually exclusive categories.
grokking blocks and the block hierarchy
take a document and draw boxes around each of the block type elements (the spec’s TOC serves as a great reference list). If you have two pen colors, use one color for container blocks and another for leaf blocks.
Why they are called blocks should be pretty apparent now.
The block hierarchy represents the block-level structure of the document. At this point we only have structure, but no text content, i.e. the string of words you are reading now. This is where inline elements come in.
grokking inlines and the inline hierarchy
take the same document as before, but this time underline each of inline type elements (again, reference the spec TOC).
First underline the smallest elements, e.g. this run of strong text, and then draw a separate underline for the containing run of text, e.g. from the beginning to the end of this paragraph. This will help you see that inlines themselves form a hierarchy.
I think the spec doesn’t try to explicitly explain this, and only alludes to it in the Blocks and Inlines section from which you quote, because this is the standard way most (all?) structured text documents are modeled, including HTML, the DOM, LaTeX, reStructuredText, DocBook and Markdown. The spec is not targeted at Markdown users but Markdown implementers. I think it was fair to assume that anyone serious about implementing Markdown is already familiar with this model.
I hope I helped you understand!