@ypercubeᵀᴹ Well imagine you need to find (7, 1234567) in a b-tree with an awful lot of 7s in the first position, but very few 1234567s in the second key position. A lot of the time, while navigating the b-tree levels using binary search, comparing the stored key value to 7 will not be enough to decide which way to go next (this, up, or down).
So you'll need to compare two keys quite often. In the reverse case, the first key comparison (at whatever level) will most likely determine which direction the binary search goes next.
Consider a page that must contain the target row if it exists. The indirection vector is sorted by (a,b). We start with the middle record and test a, finding the value 7. We are looking for 7 so we must test b as well to see if we have found what we're looking for, or if the next search should be halfway before the current position, or halfway after.
In the reverse case, our first test is very unlikely to find 1234567, so we immediately know whether we need to search halfway before or halfway after.
(also pretend the 7 and 1234567 aren't fixed-length fields, but placeholders for values of arbitrary type)