The question is, what are the use-cases of the implicit type conversion operator which won't render my code much more difficult to understand?
When the types aren't unrelated (to programmers). There are (rare) scenarios where you have two unrelated types (as far as the code is concerned), that are actually related (as far as the domain or reasonable programmers) are concerned.
For example, some code to do string matching. A common scenario is to match a string literal. Rather than calling
IsMatch(input, new Literal("some string")), an implicit conversion lets you get rid of that ceremony - the noise in the code - and focus on the string literal.
Most any programmer will see
IsMatch(input, "some string") and quickly intuit what is going on. It makes your code clearer at the call site. In short, it makes it a bit easier to understand what is going on, at a slight expense of how that is going on.
Now, you might argue that a simple function overload to do the same thing would be better. And it is. But if this sort of thing is ubiquitous, then having one conversion is cleaner (less code, increased consistency) than doing a pile of function overloads.
And you might argue that it is better to require programmers to explicitly create the intermediate type so they see "what is really going on". That is less straightforward. Personally, I think that the literal string match example is very clear about "what is really going on" - the programmer needs not know the mechanics of how everything happens. Do you know how all your code is executed by the various processors your code runs on? There is always a line of abstraction where programmers stop caring about how something works. If you think that the implicit conversion steps are important, then don't use the implicit conversion. If you think they're just ceremony to keep the computer happy, and the programmer would be better off not seeing that noise everywhere, then consider it.