It has to do with the implementation of slot_getattr, which tries to do the deform on-demand lazily.
if you do select a,b,c, the execution would do slot_getattr(1) and deform a, and then slot_getattr(2) which reparse the tuple to deform b, and finally slot_getattr(3), which parse the tuple yet again to deform c.
Where as if you do select c, b, a, it would do slot_getattr(3) to deform c, and in the process deform a and b in one pass. Subsequent calls to slot_getattr 1 and 2 would find the attribute ready and available, and return it (without parsing the tuple again).
If this was the case, changing column order would lead to performance increase, not decrease as reported.
My guess would be same as Amits, it's most likely the additional projection step.
