I agree with you almost completely.

Though, I see an advantage in having a MOP and it is that you can mix extensions working at the meta-object level in a sane way. For instance, in bare Perl, it is quite easy to write a class that uses AUTLOAD to create methods on demand, but then, if you try to use again AUTOLOAD in a subclass, everything becomes a mess. Having a protocol eliminates that kind of problems. Cooperating becomes easy... and before you say it, yes, I agree, there are very few cases in practice where this is a real issue! but having a common language is also a good thing, otherwise you end writing your own ad-hoc mini-meta-protocols.

The main problem I see in Moose is actually not in Moose per se but in so many programmers using it wrongly. Abusing it. Creating overcomplicated inheritance/roles structures. Adding abstraction layers where they are not required. Type-checking everything... it reminds me of the first days of the web when people felt obliged to use all the HTML tags in every page.

Then there is the performance issue: the high setup time which breaks the you-pay-for-what-you-use principle that any good MOP should honor. For comparison, in Common Lisp/CLOS (which is at least as feature rich as Moose), defining a class that does nothing requires virtually no time:

$ echo "(defclass foo () ())" | time sbcl
This is SBCL 1.2.3.debian, an implementation of ANSI Common Lisp.
...
* 
#<STANDARD-CLASS FOO>
* 0.00user 0.00system 0:00.00elapsed 140%CPU (0avgtext+0avgdata 32360m
+axresident)k
0inputs+0outputs (0major+901minor)pagefaults 0swaps
[download]

While in perl, just loading Moose is on the order of the thens of a second:

$ echo "package Foo; use Moose;" | time perl
0.13user 0.00system 0:00.13elapsed 100%CPU (0avgtext+0avgdata 19492max
+resident)k
0inputs+0outputs (0major+3909minor)pagefaults 0swaps
[download]