Not all fears-of-abuse are equal. If the cost of abuse is incomprehensible code locally, there's a remedy for that: don't do it where it leads to a lack of clarity. Social pressure will prevent widespread abuse. I think that's the lesson from Dynamic Member Lookup: we don't need to legislate restrictions because good design sense will prevail over time.
However, if the cost of abuse is a fundamentally inefficient compilation model, everyone pays for it and there's no good remedy for that. Perhaps library A and library B both add an implicit conversion, and in isolation both are fine---small bump in compilation time that they don't notice. But a client of A and B starts to hit exponential behavior in the type checker. What's the remedy here, when we've provided a general feature that doesn't scale? The ExpressibleBy... protocols are an interesting historic example here, because their design contributes to worse type-checker performance. The generality of that feature has a cost paid by everyone in terms of build times, but there's no one thing to point to that a user did that admits a localized fix.
I think generalized implicit conversions are in both of the categories above. While we can debate whether the fear of abuse is justified for the former category, it's the latter category that's the larger problem: the presence of even well-intentioned implicit conversions can degrade the overall Swift development experience without any single point of abuse that can be corrected.
I don't know if we have that unifying theory. @johnno1962 implies that the solution he was experimenting with cannot account for many of the existing conversions:
I'm not sure; I think many of the implicit conversions that exist today could be subsumed into a general design.
To be clear, a C++- or __conversion-like design is specifically the one that's being pitched. I think something more akin to subtyping of value types would be a more reasonable design, but it still opens us up to exponential behavior.
Doug