Go is on the other end of the spectrum; they have tuned their syntax to be fast to parse, and have stuck to implementing existing compiler technology. If your semantics are very far removed from how computers work, you need a very advanced compiler like GHC.
It sounds like Perl6 is somewhat centrist in its approach, and has innovated quite a bit; I think it will be possible to almost match Perl5's speed with reasonable effort. The interpreter might do well on small examples, but the VM will dominate in very large ones. Many compilers are tiered in that they use an interpreter for cold code, and spend the effort to generate code and JIT hot code.
Bleed commits on VM for example, recently passed Perl 5 on speed with read-a-million-line-file-and-sum-up-number-of-chars bench ( https://twitter.com/zoffix/status/895684203550973956 ).
The “bleeding edge” is a more recent term for the same idea, emphasizing that being at the cutting edge might involve danger to yourself.
We're only talking about on the order of a million bytes in your example, so 2 minutes to process on the order of 1 megabyte with a regex is just insane. If you applied it to 1 gigabyte of files that would be an even 2 days vs Perl 5 @ 16 minutes.[1] Sixteen minutes isn't enough to rewrite it in C, so Perl 5 is "fast enough". You can go get a coffee or think about the next thing you want to do with the data, or write the next part of your processing. But two days is prohibitive: it breaks your workflow.
[1]
time yes | head -n1000000 | perl6 -e 'for $*IN.readchars { .subst("y", "n").print }’
This sounds like a disaster waiting to happen.
I usually don't program in Perl, but occasionally use it instead of sed.
Compare, Perl 5 vs. Perl 6:
Spending several minutes to do what can be done in under 1 second is just unacceptable.