I think that if you include built-in operators as (shorthand for) method calls, and you count the number of occurrences in typical Python programs rather than the number of distinct species, it's common.

I don't know if I necessarily support this idea, but it makes sense as a generalization of the existing augmented-assignment syntax to operations that are conceptually similar, but are written with method-call syntax because Python lacks operators for them.

The fact that methods are inconsistent about mutating in place versus returning a new object, and it's sometimes hard to guess from the name which will happen, is unfortunate but I don't think this proposal makes the problem any worse.

Here are a few cases where the syntax would be useful for values other than strings:

    named_tuple .= _replace(...)
    pil_image .= crop(...)
    numpy_array .= transpose()
    node .= get_{parent,left_child,right_child}()
    mutable_thing_from_caller .= copy()

What I dislike about this syntax is that it makes no grammatical sense since . isn't a binary operator and the thing on the right isn't an expression.