Could you please elaborate on why TestScope counterparts of stabilized functions (e.g. TestScope.runCurrent) are left experimental?

1. Time control is heavily misused: see most examples in https://grep.app/search?q=advanceUntilIdle. There are almost always alternative ways to express the same intent without the magic of "and here we stop until we magically know that there's no more work to be done". Almost all examples of using time control in the wild are just of the form launch { ... }; advanceUntilIdle() or launch { some non-suspending action }; runCurrent(). This could be replaced with job.join(), or even better, when we fix Dispatchers.setMain does not implement a correct Dispatchers.Main.immediate #3298, many of such launch calls will just execute undispatched, and this won't even be needed. So, I think that time control shouldn't be so prominent.
2. When one does want such "stop the world, I want one particular execution, and I am going to get it" magic, the time control does not provide this behavior in case of external dispatches. You only get the behavior you asked for when you only use the test scheduler and nothing else. TestScope doesn't highlight this on its own: calling advanceUntilIdle in the middle of the test, one could easily forget that waiting for a network request to return a value is also considered to be idleness. So, I think time control should be syntactically linked to the test dispatcher.
3. All that said, I've seen actual use cases where time control significantly simplifies tests. This is all in fairly advanced cases, so the users know what they're doing and can afford to search a bit for time control capabilities. So, I think that, sufficiently hidden from the public eye, time control can be useful and we should stabilize it for the scheduler.