MHO, not some sort of policy.
Other than the time spent updating for the upstream refactoring (which, personally, I don’t think should stop you—but maybe see how much you can mitigate it?), I don’t think this would make much difference to the Swift compiler either way.
Swift needs to embed and use much of clang—the preprocessor, parser, AST loader, Sema, and I think some of IRGen too—for our C-family interop features. We also use some of the clang components you're thinking about moving in our diagnostics and other infrastructure, but moving these to LLVM wouldn't free us of our clang dependency, so we're not really itching to see it happen.
In fact, we actually don't use some of the things you're considering moving—we have our own equivalent to
SourceLocation because clang's is overengineered for a language without textual includes, and our compilation model is too different from C's to use much of clang's driver. (We're actually working on a new llbuild-based driver implemented in Swift.)
So I don’t think we would gain from the refactoring you're suggesting, but if it makes sense for other LLVM projects, we're certainly not opposed. We’ll have to adjust, but adjusting to upstream refactoring is the cost of doing business in the LLVM ecosystem.