The answer to your question is that you are correct. In a fixed timestep game loop you don't need to pass in actual 'deltaTime' or time since last render. You pass in a fixed timestep (dt constant) so that the physics simulation steps the proper amount of time.

In that code,

integrate( currentState, t, dt ); // integration

dt is the length of time each physics step should be calculated for, or integrated. That's why it needs to be passed into the Integrate function. The physics code needs to know how much time passes between calculations.

If you do position += velocity and process that 30 times a second, it'll be quite different if you process the same thing 15 times a second. So you add the dt variable so that if your fixed timestep is 30 times a second, your object will move the same distance if you're using a 15 times per second timestep. You're only changing how often the physics simulation is integrated. That's why you have to pass dt into the calculations.

The separation of physics and render happens next.

Actual uneven deltatime is the frameTime variable and is added to the accumulator. So if too much time has passed since last render, the loop might need to process multiple physics steps before the next render. But each of those physics steps is calculated on the fixed time step of dt.

Then in the rendering code you adjust based on how much in between physics steps we are. That's where the alpha is calculated and interpolated between previousState and currentState.

const double alpha = accumulator / dt;

State state = currentState * alpha + 
previousState * ( 1.0 - alpha );</code>

If you don't do this, rendering will be choppy and essentially tied to the physics step. But since rendering varies in time between each frame we want to interpolate and it makes the rendered objects smooth as butter. Let's say you render three times between each physics step, you don't want the object to render in the same place each of those three renders waiting for the next physics step. You interpolate so the rendered object will continue to move even though the physics simulation hasn't stepped yet.

I use this in my games and it works great!

And someone else asked about the .25s max_frameTime. Correct, that avoids the spiral of death. If the time between renders gets too big, you just truncate it to keep the system from crashing. Everything will start to get choppy and miss frames but at least it won't crash.