Der Irrglauben es gäbe noch keine Perl6 rührt daher, das die Entwicklung für Perl ungewöhnlich ist.
Zuerst wurden alle Wünsche zu Perl6 gesammelt und zusammengefasst. Das ist das was mal als Perl6 bezeichnet. Es ist die Sprachspezifikation.
Danach begann man mit Perl6 Implementierungen (Rakudo ist einer der bekannteren). Die Leute in der Planung arbeiten eng mit denen zusammen, die Perl6 Interpreter programmieren. Dabei tauchen immer wider Probleme und neue Ideen auf. Das hat zur Folge, das egal wie weit ein Interpreter ist, es immer noch eine lange Liste von Dingen gibt, die Implementiert werden müssen.
Außerdem ist es eine sehr abstrahierte Sprache. Man programmiert auf einem sehr hohen Abstraktionsgrad, das hat zur Folge das der Interpreter einiges verwalten und beachten muss, das macht diesen komplex und ohne die Optimierungen langsam.

Rakudo hat mittlerweile einen Stand erreicht, das man damit Programmieren kann.
Ich teste es schon und es ist eine wirklich gute Sprache.
Dennoch arbeite ich weiter mit Perl5, da der Interpreter einfach ausgereifter ist. Es ist für jede dynamisch typisierte Sprache schwer an die Qualität des Perl5 Interpreters heran zu kommen.

Es wird weiterhin immer behauptet Perl6 habe Perl5 getötet. Das Gegenteil ist der Fall, mit Perl6 kamen neue Leute zu Perl5, Cpan wird überschwemmt mit neuen Modulen und alte werden wieder gepflegt. Eine Menge neuer Features hielten in Perl5 Einzug. Die Entwicklung des Interpreters hat sich beschleunigt. nicht mehr alle paar Jahre gibt es eine neue Version sondern einmal im Jahr.
Es passiert eine ganze Menge.

Immer wider taucht die Behuptung auf man könne in Perl keine großen Projekte schreiben, da die Sprache zu chaotisch wäre.
Es stimmt, Perl ist eine sehr variable Sprache, die einem viele Freiheiten gibt. Und man kann damit so Programmieren, das es aussieht als wäre jemand auf der Tastatur herum gesprungen. Aber man muss es nicht. Man kann Perl aussehen lassen wie C++ oder Java, man kann es etwas wie Python aussehen lassen, oder wie Ruby.
Man kann mit Perl strukturiert Programmieren und man kann damit so programmieren, das man den Code in 10 Jahren noch versteht. Aber man muss auch sehen, das es Disziplin erfordert.

Man kann so was schreiben um eine Datei zu lesen

my $data=eval{local($/,@ARGV)=(undef,$file);<>};

Man muss es aber nicht:

my $data;
if( open my $fh, '< ', $file )
{
local $INPUT_RECORD_SEPARATOR = undef;
$data = readline $fh;
close $fh;
}

oder objektorientiert:

use IO::File;
my $data;
if( my $fh=IO::File->open( $file, 'r' ) )
{
$fh -> input_record_separator( undef );
$data=$fh -> getline();
}

oder man benutzt etwas fertiges:

use File::Slurp;
my $data = read_file( $file ) ;

Aber möglicherweise ist es diese Varianz die viele verschreckt. Viele scheinen zufrieden zu sein, wenn es nur einen einzigen, nicht ganz perfekten Weg gibt ein Problem zu lösen. und schreiben dann lieber den dreifachen Code um ihr Ziel zu erreichen.