So you can get compiler warnings when you accidentally try to shadow an 'only' sub definition in the same scope when you are not using multis.
No other language needs this. In both perl6 and Java for instance it is illegal to have 2 functions of the same exact signature in the same scope, and multi doesn't change that (how would it). NOTHING is gained by multi, except added syntactic complexity and the need to revise existing code when adding a new method/function that has the same name as an existing one, which is fairly common. By itself this is trivial, but perl6 commits this same sin again and again in different ways, meaning you have remember many non-value-adding syntactic rules. Its just poor language design and smacks of some sort of 'ashcan design' where everyone stuck their nose in and added an extra bad idea.
why is there sub and method as separate things in the first place
Because calling conventions are customized to OO in methods -- you have an invocant, and unknown named parameters are, by default, ignored so you can easily subclass.
But again, other languages don't need this, and neither does perl6. If such calling conventions are 'good' then why not use them for all subroutines? Surely they aren't better for methods than they are for other function calls. Why not allow either style of call for the same function without needing extra syntactic noise? Surely a compiler can distinguish one type of invocation from the other! This again removes an entire extra keyword and in fact would also remove other related oddities.
and WHY is 'sub' changed mysteriously to '->' when the method is anonymous
anonymous subs using "sub" still work. '->' is a generic closure syntax which you may prefer if you like it.
OK, fair enough, I didn't see where 'sub' was still supported in this context, but that's fine. Personally I find '->' ugly and cryptic, but to each his own!
I'm having a hard time seeing what was gained
It's as much about what was lost than what was gained -- Perl 6 leaves behind a lot of the things that demanded a spirit of loyalty to put up with, like variant sigils, so it will be less irritating to a wider audience. The whole language is much more self-consistent, and things that would have required a complete overhaul of Perl 5 to implement have not had to contend with the obstacle of backwards compatibility.
Honestly, its a bit sad. I liked the perl community pretty well, but I guess the world moves on. perl5 seems unlikely to acquire portability, usable multi-processing, or other really advanced features. Its still a decent language with wide support, but it seems almost inevitably doomed to slow obscurity in its little ever-shrinking niche. perl6 seems unlikely to thrive at this late juncture. I guess Ruby and Python have both long since absorbed the lessons of perl, as have other parts of the IT world. Certainly CPAN was a huge influence far beyond scripting languages. The world is better for having had perl, but I guess nothing lasts. perl6 seems more like a footnote or epitaph than something really new to me. Sorry if that's a glum assessment to a perl6 supporter, but I was one too, in 2003 or so...