Most languages give you one of two easy options. The first is to use green threads, which makes 100,000 new threads cheap, but now a single slow function call anywhere can block other threads. The second is to use OS threads, which keeps a slow function call in one thread from interrupting your responsiveness, but now makes 100,000 new threads expensive.
What M:N threading does, at least in theory, is allows you to create 100,000 threads cheaply AND keep a slow function call in one thread from blocking others. In a language with those features you can build it out of continuations (NOT coroutines) and real threads. But that requires building your own scheduler that can move a user thread to a different process at need. Which is non-trivial, and is unlikely to cooperate well with any third party libraries.
That said, whether M:N threading is a real optimization depends on a ton of things. A big one is the underlying performance of the scheduler and the language. Which is improving for Perl 6..but has a long way to go.
Whether optimizing at this level matters is another good question. Most companies shouldn't care. Those that should, should be cautious about deploying Perl 6 into a mature infrastructure.
So that's why people can think that M:N is important, and why you might legitimately disagree.
