It's massively useful for writing functional-flavoured mutation code.
Well, either a variable is mutable, then make it mutable, or it is const, then make it const. Making mutable variables const and redefining them when ever you change them in my opinion defeats a lot of the purpose of const.
Concerning that this hasn't caused problems yet:
So, my well-intentioned advice to rust is: Please be careful!
I admit I'm a little surprised; I'd have expected C++ devs to be in favour of this.
The problem never were implicit conversions between types itself. Sometimes they are truly desirable. The problem are lossy implicit conversions between types.
The distinction exists to ensure that both non-owning strings (string literals, slices into larger strings), and owned strings are efficient.
If I have a function that takes an owning string, and a string-reference and I want to call it, guess what: I want to call it in any case. In C++ I just throw my reference in and the compiler sees „There is a super-obvious non-lossy way to convert the argument so that it fits“ and does the conversion.
In Rust I have to add another call in order to do what I would do in any case. It's not that I write faster code that way, I just end up writing more code.
Currently, I believe the language will implicitly coerce from a &String to a &str
Ok, there wasn't when I checked the last time, but if it is there now, this would greatly reduce the pain.