At the moment, sorting and reversing should only be faster for things that don't have identity (like integers and floats). If you look at the source on github (see list.fs and local.fs), both copy the list into an array, sort the array and then recreate the list.
When you use sortDescending it sorts the array with stableSortInPlaceWith, which always uses stableSortWithKeysAndComparer. This function, after the sort makes a copy of the result and adjusts duplicate items so they are in the original order. It's a stable sort so duplicate items won't move around.
Sort uses stableSortInPlace, which has an optimization to detect things like floats with no identity so there's no need to use a stable sort; no second copy is made making it faster. If it was a list of objects, List.sort then uses stableSortWithKeysAndComparer so it should be the same speed as List.sortDescending but then slower because of the reverse. For my tests it was slower but hard to really tell for sure as my VM is on shared infrastructure and was giving wildly different results.
[1.0..1000000.0] |> List.map Some |> List.sortDescending;;
Real: 00:00:13.616, CPU: 00:00:13.275, GC gen0: 146, gen1: 12, gen2: 5
[1.0..1000000.0] |> List.map Some |> List.sort |> List.rev;;
Real: 00:00:17.727, CPU: 00:00:17.316, GC gen0: 149, gen1: 15, gen2: 6
As pointed out in the comments, the list is already sorted making the List.sort much faster (last I looked, .NET used a quick sort for arrays, which is fast if already sorted). However, even if you reverse the list first, List.sort |> List.rev is still faster than List.sortDescending when it's a list of doubles.
One more note, the two are not actually equivalent for all cases. Because it's a stable sort, the duplicate items will be in the same order after List.sortDescending, but they'll be reversed by List.sort |> List.rev.
