At compile-time, it absolutely does (ignoring optimizations when the compiler happens to be able to see all the code). At run-time, it gets a little tricky: you can do dynamic checks (that's what as? is) but the context in which you perform the check is separate from where the type was defined, or where it was coerced into an Any. This can be a problem if there's more than one conformance available (something that only happens today with retroactive conformances, but which would apply to mixin conformances as well).
In my case, though, there isn't a witness record (conformance descriptor) for Concrete: Mixin, only Concrete: A, Concrete: B, A: Mixin, and B: Mixin. Should dynamic casts do an unbounded amount of work to figure out whether Concrete: Mixin can be formed?
(The answer could be yes! Since it can easily be cached, at least. I'm not sure whether that would be my answer, since it makes the cost of as? go up, but this particular issue has a solution that doesn't immediately contradict a design goal. as? may already have to scan through all loaded libraries if it's the first time a particular dynamic check is performed.)
Well, yes, Swift shouldn't be a copy of one other language, but it is absolutely a synthesis of good ideas from other languages (struct semantics are very much like copyable types in Rust, enums are almost directly sum ADTs from several other languages, classes are a lot like Objective-C's but with a C++-style dispatch, protocols behave a lot like ML conformances but associating them with a particular type like Java/C#). If there's one thing that Swift has really innovated on, it's having a stable ABI with non-uniformly-sized values and a non-trivial generics system. No other major language does that as far as I know.
If there's a new idea that's really good, we should definitely consider adding it to Swift. But a new idea is harder to evaluate since we don't know its trade-offs yet.
@Kentzo's comparison to Scala implicits is spot-on, and I'm sorry I didn't concur with that sooner. I think such a feature can be reasonably designed—"if the compiler can't see any other way that this type conforms to this protocol, use this implementation" or even "use this implementation instead of how the type normally conforms to the protocol"—but the trade-off we get is that the conformance might behave differently than one used elsewhere in the program, and that's not currently something that happens in Swift (except, again, in the retroactive conformance case).
What if we split it up into two proposals: a way to use alternate conformances explicitly, and then after that a way to do that implicitly? I should warn that the second one is likely to get a lot more resistance; besides overloading, there aren't that many features in Swift that kick in implicitly. But the first step is something the runtime already (mostly) supports, and you could see types that look something like this (not really proposing this syntax, just for understanding):
Set<Int where Element: Hashable = CustomHashable> // replacing a specific conformance requirement
Set<Int in IntWrapper> // replacing a type, along with all its conformances
Set<@IntWrapper Int> // using property wrapper syntax
It's less obvious how to apply this to generic functions, but :-/