What does it cost us?

For me the method notation is an _alternative_ not an obligation (TIMTOWTDI).

YMMV and I'm not radical about it.

I don't wanna repeat all given arguments in details, so just telegram style:

• autoboxing allows a method API at primitive types, that is normal operations like ++ have no speed penalty.
• avoid multiple parens, e.g for dereferencing like @{ ...}
• readability! With 2 arguments the methodname and not a comma separates in between like a binary operator  xxxxx->push yyyyy
• in deeply nested datastructures the operation is written next to the addressed element
• ease of porting from other languages
• no need for prototypes
• mutators highlight the changed argument on LHS

I agree that upper $foo is easier than $foo->$upper but I personally prefer

$personal{Berlin}{employee}[9]{name}->$upper to see that the name is uppercased.

and better $personal{Berlin}{employee}->length() than scalar @{ $personal{Berlin}{employee} }

update

> reads like a sentence in English,

After some meditation, I realize that many exceptions to "reads naturally" rule in Perl are just ignored, which cause a logical break.

For instance nobody says

"rewrite from personal in Berlin which is employee of Number 9 the name".

rewrite( $personal{Berlin}{employee}[9]{name} )

You rather say "rewrite the name of the 9th employee in the Berlin catalog of employees"

The problem is that nested data structures are top-down, but we can't code

rewrite {name}<-[9]<-{employee}<-{Berlin}<-$personal

(well we could, but how likely is that to be implemented?)

OTOH human language is flexible enough to use a passive voice construct

"From the catalog of Berlin the employee number 9's name has to be (or is) rewritten."

$personal{Berlin}{employee}[9]{name}->rewrite()

I hope you get the point, with deeply nested top-down data structures a method call helps to put the verb near the subject.

Just read methods as passive constructs.