The Java EE spec doesn't "allow" spawning of threads, but application servers don't police this, and, as you say, threads are commonly spawned from within Java EE apps, which works just fine.
The intent of the spec was that the application server owns threads and therefore can be configured by a system administrator to manage an "optimal" number of threads for the combination of hardware, OS and Java EE apps in question. The developer of a Java EE app, so goes the thinking, doesn't have this holistic picture and so can't be trusted to manage a system-wide resource such as threads from within her own little app.
In reality, though, the only important thing to remember is that threads are scarce and the application server potentially manages a lot of them, therefore the ones spawned from the app should be of a number and lifetime that plays well within those constraints. And if you need container services (transactions, security) on those threads, then you're currently (spec-wise) out of luck (see Martijn's post and Java EE 7).