The conflict may not be known until much later, for a crate that has nothing to do with either. Crates A and B may be fine together, as well as A and C, as long as they're not all together. But way down in crate Z they've ended up with a dependency tree that includes all three, and they'll get your error with nothing they can do about it.
That may happen across time too. Suppose A, B, and C do all work together in Z. Then B adds some impls in an update, which works fine for them, but now Z breaks.
It would be very annoying if you couldn't depend on some two crates at the same time (or two versions of the same crate!).
Another issue is that if you implement impl Bark for Dog, and then later the author of the dog crate also implements Bark for Dog (in a minor semver revision!), your code now stops compiling and you have no easy way to fix it.
Because it would be a semver hazard, and a time bomb for the ecosystem. It's very valuable that crates can be freely composed, and that they can provide reasonable stability guarantees. Without orphan rules, neither of that is true, since an unrelated crate could add an impl which breaks your entire build.