In what sense is it not defined?

The element has as a content model "text", and along with <title> is defined as one of the 2 "escapable raw text elements", so having child nodes inside them is invalid.
Thus said, in <title> it is stated that:
[The IDL attribute 'text' must return a concatenation of the contents of all the Text nodes that are children of the title element (ignoring any other nodes such as comments or elements), in tree order. On setting, it must act the same way as the textContent IDL attribute.]
This requirement helps handling invalid cases.

For <textarea> the normative previsions often refer to the element's textContent IDL attribute: 
[When the textarea element's textContent IDL attribute changes value, if the element's dirty value flag is false, then the element's raw value must be set to the value of the element's textContent IDL attribute.]
[The reset algorithm for textarea elements is to set the element's value to the value of the element's textContent IDL attribute.]
[The defaultValue IDL attribute must act like the element's textContent IDL attribute.]

Following the reference to the textContent IDL attribute in the DOM specification, the explanation is:
[The textContent attribute must return the following, depending on the context object:... Element - The concatenation of data of all the Text node descendants of the context object, in tree order.]
"Text node descendants" are the text node children and the text nodes inside descendant elements, I guess.
So in a case when the DOM for this element can be represented like this:

     ...
     |
     +-- HTML textarea element (node 1)
     |    |
     |    +-- #text node: "hello" (node 2)
     |    |
     |    +-- HTML em element (node 3)
     |    |    |
     |    |    +-- #text node: "cruel" (node 4)
     |    |
     |    +-- #text node: "world" (node 5)
    ...

so far the raw value for such an element, according to the hints in the spec, should be "hellocruelworld". In XHTML documents, this behavior is followed only by IE (version 11, for what I know; emulation of previous versions is not reliable IMO). This browser, in fact, shows as value the whole textContent of textarea, i.e. its children text nodes and the text content of children elements (already (invalidly) present or inserted via javascript), even formatting the elements with default defined graphical appearance (bold for b and strong, italic for i and em, and so on). The API value and the submission value return the textContent without elements (of course), as stated before.
The other 4 major browsers do not show children elements' text content and as API value and submission value return only the children text nodes.
I know that it's an edge case, but it would be better if the spec explained the origin of the "initial value", especially if the intended purpose was the same of <title> element (i.e. only children text nodes), also considering that 4 out of 5 browsers behave this way.

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2867

Safari and IE do descendant text nodes.
Chrome and Firefox do children text nodes.

Doesn't seem that compelling to change, given that this only affects invalid content anyway. But maybe someone from Chrome or Firefox has an argument to make for why their way is better?

Created attachment 1449 [details]
Provided example rendered on Safari 5.1.7 for Windows 8.1

Safari 5.1.7 for Windows does children too.
I know that it's just stuff related to invalid documents, it's only a matter of completeness (or browser compliance if the correct version is descendants, which seems more logic).

Safari 5.x is obsolete (even though it's the latest version on Windows).

Given the lack of compelling arguments to move away from the Safari/IE model here, I've left the spec as-is. Please reopen the bug if there's a reason to prefer the Firefox/Chrome model.