The way I see it, there are several options:

(1) If the document contains only the literal, and the literal is known not to contain a '...' line, then the following will work:

The literal
goes here.

(2) If the document contains more stuff and/or is not guaranteed not to contain a '...' line, then the content must be delineated somehow. In this respect, YAML is no different from JSON (using "..." or [...] or {...}) or XML (using <foo>...</foo> or <[CDATA[...]]>). YAML gives two options here:

(2.1) Indent the literal by one space (as suggested by Ingy). In this case you maintain YAML's readability advantage.

(2.2) Convert it to a double-quoted string. In this case you lose YAML's readability advantage; you are basically using JSON (so any complaints about this format apply to JSON as well).

In either case, detecting when the content is done is trivial (the '...' line, EOF, the closing ", a less indented line, etc.).

As to why YAML does not offer a "here document" format, the reasoning went basically as follows:
- Here documents are less readable than indented literals, and YAML's #1 priority is readability
- Here documents are only a bit easier to generate than indented literals (seriously, how hard can it be to append a few spaces after each line break?)
- Non-indented literals serve as a limited form of a "here document" (with a specific set of terminators: '...', '---' lines).
- We already have a less-readable format that allows for arbitrary text (double quoted).
There's simply no advantage to "here document" to justify complicating the spec to support it (god knows it is complex enough already).

Have fun,

    Oren Ben-Kiki