TL;DR The core of your argument makes sense but you're applying it too broadly.
You're right that the fixed amount, whatever the fixed amount is, is going to be an arbitrary approximation. But sometimes an arbitrary approximation is all you need.
For example, a service that repeatedly polls an external resource, either until some condition is met, or indefinitely. The simplest way to implement that is to have a loop (usually
while) which contains a fixed delay in its body. Without that delay, you'd be polling your resource way too quickly.
I strongly believe that we should never delay like that - we should find ways to ensure whatever the dependency, it got finished, without delaying blindly and hoping it finished.
Look back at my example. The resource we're waiting for is external to our application. How can we know that it's complete, if not by polling it? But we don't want to poll thousands of times per second. Therefore, we need to slow down our polling. And how do we do that? By delaying.
The core of your argument makes sense but you're applying it too broadly.
Generally, async/await will provide better knowledge on when a resource has finished. However, there's is no guarantee that an awaited task will be resumed exactly when it is finished. It may take longer if there are no threads available when the awaited task completed.
A delay, more specifically a sleeping thread, is guaranteed to resume exactly after it ends, because it never abandoned its thread so it can ensure that thread's availability when it wants to resume. There may be use cases where this is preferable.
When dealing with frame rendering or animation, using delta time is generally more preferably due to the ability to dynamically adapt to the timing between frames (and how to handle an unexpectedly longer/shorter timing).
But delta time is not a simple thing to implement, and an implementation of that complexity is not always warranted. If you're making a slideshow where the picture changes once every few seconds, an fixed delay would be perfectly appropriate as humans won't notice the difference.
Similar to delta time, you could implement a stopwatch, track the time a certain process took, and calculate your delay time based off of it, e.g.
await Task.Delay(5000 - sw.ElapsedMilliseconds).
But again the question is what you stand to gain by that dynamically calculated delay time. From an engineering perspective it is more elegant, but just because something is more elegant does not mean it is more useful.
That implementation brings with it a bunch of new considerations. Stopwatches are may not have the precision you're looking for. You have to manage stopwatch resources everywhere. What if the measured task takes longer than your maximum delay time? How many bugs are you going to encounter before you regret taking this unnecessary-but-more-elegant approach?