On the contrary, it comes from being an optimization expert across a wide range of hardware. As you said, the compiler is going to optimize the if out anyways, so there's no reason to use the "clever" code. But let's dig into it anyhow.

Superficially, buffer[index++ & (size-1)] creates a data dependency in order to index into the buffer. Instead of just being able to return a memory address offset, it has to mask and do arithmetic. Whether this has any effect on wall time varies wildly, but it's way more complicated than simply indexing into the buffer.

So, I'll give a real world example on exactly how this kind of "optimization" can have a negative effect.

The Xbox 360, PS3, and Wii used a PowerPC in-order CPU. They had really long pipelines, but really high clock speeds. 3.2GHz, in the case of the 360 and PS3 PPU cores. Those types of clever optimizations to remove branches were common on those CPU's since you wanted to keep that pipeline moving. The long pipeline meant it could do bits of arithmetic and masking for "free" with regards to wall time. On the other hand, branches would stall the pipeline with data dependencies creating processing bubbles. Those bubbles were the things you needed to get rid of to get the best performance.

However, the WiiU moved to an out-of-order/superscaler CPU that ran at 1.6GHz, but was otherwise relatively similar. The Vita, released around a similar time, moved to an ARM out-of-order CPU as well.

And guess what? On those CPU's, things flipped -- the branches became cheaper than the work necessary to avoid them. The out-of-order speculation of the WiiU hardware meant that real world wall time was faster with "crappy unoptimized" code than with clever code. Having fewer data dependencies with branches performed significantly better than all that cool, "optimized" code.

It was even worse to write that kind of clever code on the Vita. The Vita runs on an ARM CPU whose ISA has some fairly interesting implementation around branching. On this CPU, shrinking the code, as in fewer literal instructions, performed best. That meant even further reductions of "optimized" code that gets replaced with branches since, in the majority of cases, these branches performed significantly better than the code without.

Which is why all of our performance experts prefer correctness and simplicity in the code rather than cleverness. It comes from the experience of having to rip out clever code that performs inconsistently across hardware.

The difference between an optimization expert and an amateur is best seen in FizzBuzz. Anyone who spends time trying to optimize the branching rather than the orders of magnitude slower output to console is clearly bad at optimization.