There are many questionable statements here, but the one I will address at the moment is the relation you draw between the complexity of the grammar (specifically you speak of "the more operators") the slower the language. That is simply not true.

Operators are nothing more that first class methods (or functions, depending on the paradigm). First class means that they have their own syntax.

The compiler might have to do a little bit more work parsing a complex grammar, but this has little to do with execution speed. For instance, the worst case scenario is Perl5/CGI where the application needs to be compiled for each request served. Even in this environment, perl5 is plenty fast for more needs. Options like modperl and perl6 (which can be compiled) eliminate this overhead.

Regardless, once compiled the number of operators a language supports has nothing to do with runtime performance. All operators (just like all methods) get boiled down to a set of simple instructions. For instance, the Standard Java Library as of version 1.6 has over 4000 public classes (and who knows how many private ones). There may be dozes to hundreds of methods per class. None of this makes Java slow (I wrote a Sudoku solver in high-level java that solved 14-given 17-given sudokus (some of the hardest) in under 500 microseconds each).

Perl is fast because it has 10 years of optimizations behind it. Ruby is not as fast because it simply doesn't. Update: Sorry, that should have been 10 years more. Ruby is about 12 years old, perl is just over 21.