Let's start by bounding the maximum latency we can introduce this way.
The worst case is when our rendered frame falls just after the "previousState" timestamp, and alpha is very close to zero. At this point we're one full frame in the past, 20ms if we're stepping our game simulation 50 times per second. That's already at the low end compared to typical latencies in realtime online games, where similar techniques are used to transition smoothly between discrete updates from the server/host/peers. Response times of 80-100ms can still be perceived as instantaneous, so we're already in fairly safe territory.
But we can do better. :) When the current frame falls just before the "currentState" timestamp, alpha is very close to one and our latency is practically nothing! (If we're only counting latency due to the fixed timestep - input processing and display latencies still add on top of this)
In practice we'll vary between these extremes with no particular bias. So overall, at 50 ticks per second, we're displaying a state that's an average of 10 ms old. For most purposes, this is below the threshold for visual perception of synchronicity, and closing in on the threshold for synchronous audio perception too.
And we can still do better! Because not all game feedback is tied to the fixed timestep. When the player presses a button to fire their weapon, we can spawn the muzzle flash and play the shooting sound immediately in the same frame. Depending on when we are in our interpolated time span, the projectile (assuming it's a literal projectile and not a hitscan raycast) might be rendered closer or further from the barrel, but either way the player gets immediate feedback at the very earliest opportunity we could offer - even if our updates were in lockstep. Similarly, if the player presses jump, we can immediately start blending the character into their jump animation, even if it will take another physics step or two before the upward motion becomes apparent in their physics. UI changes too, like hit markers on a reticle, can react instantly according to the rendered frame time, keeping perceived latency as low as it can be at our rendering framerate.
This helps highlight an important distinction here: how does a player know when data is "old"? Yes, technically that box moving at 1 m/s is now at (0.01, 0, 0), since its most recent calculated state is 10 ms ahead of the frame we rendered with it at (0, 0, 0). But from the player's point of view, it's moved exactly 0.0166 m since the last rendered frame 16.66 ms ago, so it's exactly where they expect to see it. The only yardstick the player can use to judge what's "now" is how the game reacts to their own input, and as we've seen above a well-designed feedback system can begin to react immediately, without adding frames of latency. Beyond that it's second-order consequences of game systems reacting to the effects of player actions, or the consequences of players' reactions in turn, all of which gets swamped by the round trip time of perception to action, which is typically a factor of 10 slower than the latencies we're considering. So while the current state might be old in terms of the pure math of the underlying system, from a player experience standpoint it's often not appreciably different from realtime.
So, tl;dr: At a decent framerate & fixed timestep, the latency introduced by decoupling your game updates is minor and very manageable for most game types.
The idea of blending with "the next, not yet calculated, state" is a related technique called extrapolation. This has somewhat the opposite trade-offs: simple, linear motion is represented precisely, but things like collision reactions appear a full frame late (so you might observe two objects touch or even interpenetrate before any corresponding collision effects or sounds trigger). Complex motion can also appear jagged, as the naive prediction keeps overshooting & correcting next frame. Generally these artifacts are easier to perceive than the slight latency of a single frame of interpolation, so the main reason to go this route is for simplicity (since you can skip storing two steps' worth of transform data)
One quick aside: you mention an example of a character appearing halfway through a teleport due to interpolation. In practice this won't happen, because we turn off interpolation (or extrapolation) when applying a discontinuous change to an object. For example, if you're using Unity and have the built-in Rigidbody interpolation or extrapolation turned on, it will automatically switch to using just the most recent frame if you set the object's position or rotation via its transform, resuming blending on frames when it's moved purely via the Rigidbody.