The str type implements PartialEq<String> and PartialEq<Cow<'a, str>>, but it doesn't implement PartialOrd of the same types. Ditto for String.
Why the asymmetry?
I'm curious because I'm implementing my own pair of types where one is borrowed and one is owned (analogous to str and String), and I want to know if I should ape the asymmetry between PartialEq and PartialOrd or if there's something special about strings that wouldn't apply to my types.
I'd assume it's just an oversight - string equality is probably used more often than ordering so people added one but not the other.
Perhaps look at Path/PathBuf as the other commonly used pair of borrowed/owned types. They implement things symmetrically.
Also, I don't know how big of a deal this is given the owned types usually deref to the borrowed type. In some sense, just implementing things for the borrowed variants can reduce amount of boilerplate. Then let deref coercion kick in. It may make certain generic bounds not work as-is, but can be worked around via other means (e.g. instead of str: PartialOrd<T> type of thing you'd use T: AsRef<str> or T: Borrow<str>, as appropriate). Or just implement all the PartialXYZ upfront 
.
Another consideration, particularly for functions, is to consider taking the borrowed type directly rather than via a generic bound. So instead of fn foo<T: PartialOrd<str>>(t: &T) you use fn foo(t: &str). This can prevent code bloat if lots of different T types were substituted - each one would get a specialized version of foo (ie monomorphization). Instead, you make caller cough up a &str via whatever means and pass that directly.