I've never looked at the code that perl uses to handle regexes, both compiling and optimizing, but from just looking at it and talking through it, I can begin to see why you get different results:

1: look for at, not found, look for bt, not found, look for ct ...
2: look for [abcdef], found, look for t, not found, look for ght
3: open grouping, look for [abcdef], not found, look for gh, close gro
+uping, found, look for t
4: open grouping, look for a, not found, look for b, not found, look f
+or c, ... look for gh, close grouping, found, look for t.
[download]

Just from speaking it out I can see that 4 looks like the slowest and 2 looks faster than 3. I too was puzzled by 0 until I look at it from the view that the compiler probably doesn't compile the /bt/ regex unless /at/ fails, so if the word has an 'at' in it, none of the other regexes will fail, and even compiling two or three of those regexes may be faster than compiling and processing a much larger, more complex one. That has more to do with the rules of how the boolean operators work rather than how regexes are optimized. But again, I have absolutely no clue how it's done under the hood. That's just me looking at it and talking to myself.