That’s the most pertinent question here and my answer is “no”. Making certain for scenarios more, ahem, comprehensible, to me is not worth it.
Your point that this does not introduce actual mutability and it still compiles to pure & immutable code is well-received and understood but I feel that many people will not see it that way and will start demanding more and more constructs they are familiar with.
Implementing this proposal carries a huge negative potential of “opening the flood-gates” kind.
And I can assure you I’ll be one of the first people to introduce a credo or ast-grep rule against using the new syntax in the code bases I’ll be responsible for.
IMO a good compromise would be to figure out how to extend for itself to allow for this and never allow this syntax to escape out of those borders.
Or, to put it another way: I don’t want only the runtime to enjoy pure and immutable code, I want I as the programmer to enjoy it too. 
As a matter of fact, I am not even comfortable with the current proposal but I keep submitting them to keep the ideas flowing. Which is why it gets very tiring when many comments are attempting to dismiss the problem in the first place.