I've generally used the KeyValuePair<TKey,TValue> type whenever I have data that is pair-related in the sense that one is a key to the other. If the data is unrelated then the Tuple<T1,T2> type makes more sense and I'd go with that.
Now I just read this article about why to generally avoid KeyValuePair<TKey,TValue> and prefer Tuple<T1,T2>. The primary argument being the performance benefit of Tuple<T1,T2>.
Outside performance, is there any reason a KVP would be a better choice than a Tuple<T1,T2>?
Well, the type could be considered poorly named, for one. A KeyValuePair as named should represent a key and a value. What if your two objects aren't really a key and a value, just two things? If I were to see a method or property that had a type of KeyValuePair<TKey, TValue>, I would expect the values of the KVP to be a key and a value. This is really just a matter of communicating intention and making it clear to yourself in the future, or possibly other team members. A tuple does not indicate that kind of association.
Tuples also make it easier to add another value, making it a 3-tuple (or a triplet, however you want to call it). Some .NET languages, like F#, have special syntax around tuples as well.
For an implementation perspective, Tuple does many things KeyValuePair does not. Tuples are comparable, they implement the IComparable and IStructuralEquatable interfaces, so it makes it easier to compare two tuples.