Here's what the page currently says:
Threads are sometimes implemented in userspace libraries, thus called user threads. The kernel is unaware of them, so they are managed and scheduled in userspace. Some implementations base their user threads on top of several kernel threads, to benefit from multi-processor machines (M:N model). In this article the term "thread" (without kernel or user qualifier) defaults to referring to kernel threads. User threads as implemented by virtual machines are also called green threads. User threads are generally fast to create and manage, but cannot take advantage of multithreading or multiprocessing and get blocked if all of their associated kernel threads get blocked even if there are some user threads that are ready to run.
As you can see, in one paragraph it is stating BOTH that user threads both can take advantage of multiprocessors (via associated kernel threads), AND that it cannot.
I suggest that you ask your question on the Wikipedia page's Talk page, and see if they authors can enlighten you as to what they mean ... and why they are saying it.
But what I think they are saying that user(-space) threads that aren't backed by multiple kernel threads typically cannot execute simultaneously on multiple cores.
However, I would hesitate to say that this is inherent to user threads per se; i.e. that it would be impossible to implement an OS in which a application could exploit multiple cores without any kernel assistance.
