You’re looking at unoptimized code, so studying it for performance isn’t very meaningful. If you look at optimized code for your examples, you’ll find that it doesn’t do the comparisons at all! The optimizer notices that the switch variable sc always has the value 1, so it removes the unreachable case 2.
The optimizer also sees that the variable a isn’t used after it’s assigned, so it removes the code in case 1 as well, leaving main() an empty function. And it removes the function prolog/epilog that manipulates rbp since that register is unused.
So the optimized code ends up the same for either version of your main() function:
main:
xor eax, eax
ret
In short, for the code in the question, it doesn’t matter which order you put the case statements, because none of that code will be generated at all.
Would the case order matter in a more real-life example where the code actually is generated and used? Probably not. Note that even in your unoptimized generated code, both versions test for the two case values in numeric order, checking first for 1 and then for 2, regardless of the order in the source code. Clearly the compiler is doing some sorting even in the unoptimized code.
Be sure to note Glenn and Lundin’s comments: the order of the case sections is not the only change between your two examples, the actual code is different too. In one of them, the case values match the values set into a, but not so in the other.
Compilers use various strategies for switch/case statements depending on the actual values used. They may use a series of comparisons as in these examples, or perhaps a jump table. It can be interesting to study the generated code, but as always, if performance matters, watch your optimization settings and test it in a real-life situation.