Modern CPUs execute past branches speculatively and use associative arrays (the hardware version) to remember which way specific branches went in the past. So if you’re benchmarking this with the size always equal to 3 the cost of that branch is effectively nothing.
The Julia compiler could become more aggressive about specializing code on specific Array sizes. In that case, the difference between using a dynamic-size array (Array) and a static-sized array (SArray) would get smaller. Honestly, though, I’m not sure we even want to do that. The way we do things work now is really simple and predictable: if you want to specialize on array dimensions, use SArrays and specialization is guaranteed; if you expect lots of different array sizes and don’t want to specialize on the array size, then use normal Arrays and non-specialization is guaranteed. There are cases where either one is better and the end-user is generally in the best position to know which case they’re in. As long as libraries are appropriately generic and support general AbstractArrays then this is a great way for things to work. And fortunately, Julia has a long-standing tradition of people writing appropriately generic array code in libraries. Moreover, one of the lovely things about this approach is that all code everywhere—no matter how deep the call—that loops over the dimensions of a generic AbstractArray gets specialized when you use an SArray, even if the author never thought about static arrays or specializing on array sizes.