I totally get where you’re coming from, and I understand why logically drivers could be able to extend playback. Realistically, though, playback only goes to the end frame, even with #frame driver. There has to be an upper limit on frame count.
That’s not a very helpful answer, so let me describe why drivers can’t extend playback. This is going to be long, I’m sorry, I just know the feeling of having a logical idea and being frustrated when no one will explain why it wouldn’t work.
Think about it like this: in the situation you describe, with a #frame driver, playback doesn’t stop at the end frame. It stops whenever you stop playback, right? Seems simple enough.
Here’s the problem: if you’re rendering this as an animation, how many frames does it render? “Whatever the end frame value is”, you might say. Ok, so we now we have a different frame end for renders and viewport preview. This is already a problem, because viewport preview needs to show what the render will be, but let’s put that aside and say you CAN have two different end frames.
Now we have a new problem: every frame in the viewport requires memory. In this case, not very much, since you just have one driver, but imagine you have a full armature with bones, constraints, etc, all being driven by a #frame driver. If you were to press play on the viewport render and let it keep going without an end frame, it will keep going infinitely, it will keep using memory, and you’ll run out of both RAM and disk space eventually.
We also have another problem- any fluid caches, physics caches, soft bodies, anything like that, is also using memory every frame. Without an end frame, you can’t have physics, fluids, volumes, or even particles.
Ok, so why not just have drivers extend playback unless there’s a physics simulation, or volume, or particles? Sure, we’ll run out of memory eventually, but to be fair, that will take a long time.
Two problems with that: can you imagine the confusion of trying to figure out if you could have extended playback or not with those restrictions? Having extended playback switch on and off based on a long list of memory-hogging factors would be HORRIBLE user experience, you’d never know if it was on or not.
More importantly, at this point, we’ve removed the functionality of the “viewport preview”- it’s not previewing the render accurately, and all we’re gaining is the ability to extend playback. Even that is under very limited circumstances and it comes with the GIVEN that Blender and your computer will crash eventually. It might take ten minutes or it might take a week, but eventually, you will run out of memory if you’re processing infinite frames (or approaching infinite frames.) Baking in functionality that’s guaranteed to break is something no software developer would ever do.
There’s also an upper limit to what the end frame number can actually be- it would be hard to reach, since I’m assuming it’s 9,223,372,036,854,775,807, which would take 12186300361.6 years to reach at 24 FPS, but still, once Blender reached that frame, you’d have another 100% guaranteed crash.
To summarize- yes, it would be POSSIBLE for frame-based drivers to extend playback. It would create a bunch of confusing functionality that could only turn on under very specific circumstances, and it would eventually crash your computer, so that’s why it’s not PRACTICABLE.