I get it -- optimization is a fun game. But isn't one of the rules of Optimization Club to implement the spec first, and optimize once that's been done?
That's only if you do waterfall-style development, and if you have well-financed dev team.
But we are volunteer-driven dev team, and so we must also keep those developers happy. And having a dog slow compiler frustrates people, and drives them away. And if volunteer devs have no users and no fun, they stop developing.
Another point is that we're listening to user feedback. When we first released the Rakudo Star distribution, we got lots and lots of feedback. Most of it was "this is very cool, but please make it much, much faster (and less memory hungry)".
Also, while Rakudo isn't feature complete, most user complaints these days concern performance and reliability, not features. Most missing things are very much orthogonal (and on a higher level) than the current optimization, so we don't expect much friction from adding those features later. Quite the opposite; since Rakudo is a partially self-hosting compiler, optimizing it speeds up the development cycle, which makes it easier to add more features.
Finally I'd like to point to other languages and compilers, like C++ with gcc and clang, and C# with mono/roslyn, and java with OracleJVM/OpenJDK + javac. The compiler (and VM) developers spend quite some time optimizing for performance. Yet none of the languages are feature complete, they are all being developed constantly. And not just the languages, the compilers have to catch up on those features too. Do you think they are all wrong too?