1.
Why indeed... floating-point loop logic is evil. 0.003f cannot be represented in floating-point. After say 256 iterations of this, the loop counter is now ~= -0.231997 instead of -0.232. It would be better to do this loop using an integer control expression and then divide the end-result by 1000.0f inside the body of the loop. I would not trust the author of this tutorial to write any financial software. They will lose your money by doing things like this ;)
0.003f is actually ~ 0.003000000026077032089233398438... (it is a repeating number in floating-point because it cannot be expressed as division by a power-of-two). After enough rounding errors accumulate, the difference in value can be enough to throw off your loop counting logic. So much so, that even if that number incremented in steps large enough to address only 190 slices, the loop would run 1 less time and you would be missing a slice.
If you had 256 slices, and incremented 1/256 (which is expressed using a power-of-two denominator) per-iteration, floating-point loop control would work. Alas, 3/1000 has no such property. This is a bad floating-point value to use for looping. Since finding out whether a series of numbers can be represented precisely using floating-point is a nuisance, it is usually better to avoid floating-point loops altogether.
2.
If you want 256 unique values in the range [-1.0, 1.0] (NDC coordinate space), you should start at -1.0 and increment by exactly 1/128 (0.0078125) each iteration.