As a type alias there is no real compatibility gain to be had. If both of us define (~>) as above, then types written with types against my (~>) and types written against your (~>) are
freely interchangeable, even if you might have to play with your import lists more carefully.
We can't hang any instances off of it, so almost all of the standard arguments for moving it "closer to base" fail to take effect.
On the other, other hand, something like
newtype f ~> g = Nat { runNat :: forall a. f a -> g a }
is slightly easier to make a case for, because you can hang instances off of it and share more than one line of code, but I'd be -1 on that as well, because there are a host of issues with that definition as well not being "one size fits all" either.
There are several viable definitions for a natural transformation depending on how general you want to get -- and this one (like the one in natural-transformation) conflates parametricity with naturality, so rapidly stops being good enough as you drift into PolyKinds and then start wanting a more accurate Category and Functor notions, which then force you to parameterize over the underlying `->` in the definition.
Both of these definitions occupy awkward suboptimal points in the design space, so I'd rather not see us locked into their use by enshrining either one in base.
-Edward