The reason is that those methods are there just to implement the I-interface and not to augment the class' public interface.
What I mean is that if you have the following:
public class MyClass : IConvertible
{
// implementation
}
You might want MyClass to be convertible, indeed, so you can pass references of it to methods that expect IConvertible:
public void DoSomethingWithConvertible(IConvertible conv)
But you might not want variables of type MyClass to expose the Convert methods. You simply don't want MyClass's public interface to have that method, then you implement the interface explicitly. That's the whole idea of the approach. This means the following is not allowed:
MyClass a = new MyClass();
a.Convert();
However, the following is still be allowed:
MyClass a = new MyClass();
((IConvertible)a).Convert();
The whole idea behind this is that even though we're using the exact same instance, a as MyClass doesn't have the method. A as IConvertible does have the method. Think of it as if you're allowing the instance to have split personality.
Usually I end implementing every interface implicitly. However, there are very specific situations where I'd implementing them explicitly exactly for the reasons outlined above.
BTW, thanks for the great question!
