So nearly two-thirds of respondants so far are smarter than I. They wouldn't have just run the code and clicked the corresponding option now, would they?
I suspect some - perhaps most - did just that. It's very difficult to do any other way if you don't just happen to know that _cs is lower than _ci, _as is lower than _ai, _ks is lower than blank, _ws is lower than blank, they affect the order in the order I've listed them here, and that BIN comes last, and then remember the bizarre positioning of BIN2. I included a list of ComparisonStyles and their order in the explanation without any reference in the explanation because I haven't a clue where I got in from (I verified that it still worked when I found my rather old (although I must have updated them when 2005 came along) notes on it).
Anyway, I ended up guessing wrong, partially based on a table of SQL Collation Names with sort order values found here: http://msdn.microsoft.com/en-US/library/ms180175(v=SQL.105).aspx
Despite Tom's explanations, which so far make sense to me, I don't understand how this table would have value if it doesn't bear out the actual order. Perhaps he or one of the 63% who got the correct answer could clarify this.
That's actually quite straightforward. The "sort order id" of this column is the "sort id" of page about SQL_VARIANT; that means that if two collations have the same Locale ID, the same Locale Version, and the same ComparisonStyle then (and only then) is this "sort order id" used to determine the order - and for the collations in the question, it's already been determined by Locale ID and version and ComparisonStyle, so no account is taken of the "order id". (I'm using both names, so as to match BoL on this, but using quote marks to make it obvious that the naming is adrift).
I should probably have included the above in the explanation, but I didn't even think of it at the time. I suppose I can point out in mitigation that there are a couple of things about that page and the table it contains that might have acted as warning flags. The table on that page lists only 200 collations out of the 2397 that my copy of SQL 2008 R2 has, so it isn't going to be the whole story, not even when you allow for the fact that sort order id 80 may bring that total up to 250 or maybe more by allowing many different collations that use binary order and code page 1250. The fact that this page shows that collations for different locales can have the same sort order id demonstrates that this sort order id can't be the whole of the ordering of collations for sql_variant, because the locale id is the most significant of the attributes that determine that order. The table only gives a sort order id for three of the collations used in the question, the other two are missing.
Only a small portion of the windows collations introduced for sql use in or before SQL 2000 appear to have been given sort ids. As I understand it, if two windows collations have the same locale id, locale version (I believe implies that they have the same collation version and I know it doesn't follow from their having the same collation version), and the same ComparisonStyle they will also have the same "sort order id" and hence will compare equal as collations on SQL_VARIANT values. But I could be wrong - I can't find any documentation to back that last statement up, it's just something IO seem to remember out of the misty past, and not having found any counterexamples is no guarantee (especially as I haven't looked very hard).