I mentioned this in another deeper-level followup in this thread, but I want to try to explain my position.

Perl's type system is its operators. This is why we don't have PHP's "===" and "==" operators; they try to guess at programmer's intent. Perl doesn't guess; whenever possible it reacts to known intent, which is different from guessing at intent. Our scalar containers are typeless; it's up to the programmer to decide what type to imply at any point in the program. Resorting to heuristics to decide what type a container may be is pointless; containers in Perl are typeless. What has to happen, is operators have to know how to provide a type context.

Smartmatch works fine in a language whether containers have type, and operators react to the type. It doesn't work well in a language where containers don't have type, and operators specify the type. It ends up either having a huge list of rules and heuristics that people have to consult the manual to recall, or a small set of rules and heuristics that reduces its value while still leading to less clear code than the type-specifying operators.

In short, Perl operators are chosen by programmers to impose type. Perl reacts by providing the correct type to the operators. If you try to invert that paradigm in a language where containers have no type, you end up with messy heuristics or complex rules, or incomplete operator implementations (as in a reduced-functionality smartmatch)