... it distinguish between objects and non-objects and can apply generic method calls. So what; Java does this as well and Java is not any better for it.

Java doesn't do this; that's one of the most persistent (and damning) criticisms of Java's design.

I think the issue I have is that it is not really solving anything.

Have you ever written code that has to figure out whether you have a scalar, a scalar reference, an array reference, a hash reference, a class name, an object, a tied variable, a reference blessed into a class but treatable as an opaque object and not a reference type?

Have you ever written code with the simple precondition that one of its arguments must somehow stringify sanely -- you don't care how it does that, merely that it does that -- but the mechanism for type checking in Perl 5 is so disjointed and bicameral that it's almost impossible to write a check that's both correct and not so strict that it prevents useful (and common) behavior?

Have you ever thought to yourself "Self, tie would be so much more useful if it weren't a righteous pain to use!" or "I like the idea of overload, but ... wow, what a mess!"?

I've done all three.

I fail to see the benefit of trying to make Perl act like Ruby.

I fail to see the problem of borrowing good ideas from other languages (and you mean Smalltalk, not Ruby) if they solve very real, very painful problems in an elegant way.

If you have a criticism of autobox better reasoned than "If you want to use Ruby, you know where to find it!" I'm happy to discuss that... but Perl 5's primitive obsession extrudes from the VM level and makes things like tie unnecessarily complex. Major credit should go to chocolateboy for creating something which people can experiment with to discover how the language could look without the historical baggage of implementation.