"Explicit" ties in to readability and from there, long-term support-, maintain-, and debug-ability. While OP did issue a blanket statement, this idea is fairly language/framework independent.
Yes, but it still isn't that clear cut. IMO and generally speaking, implicit is better when there is an obvious default behaviour that should be used in most cases. It may still be necessary to be able to override that default behaviour, but having to restate the obvious everywhere is not something that is good or desirable for the points you mention, since it will only make it harder to see what the differences are compared to the common case.
Of course, not all problems have default solutions and those should usually not have default behaviours.
To be honest, I'd rather state the rule as following when designing an API: "Do the obvious thing". Sometimes that will involve explicitness, and sometimes it will involve implicitness, but almost always it will be a mixture where some aspects are explicit and some things are implicit. The hard part is figuring out what should be which.