The difference between a lot of OS/app progress bars for IO (and sometimes CPU) operations and these timers, is that the total length of time for a lot of IO operations is often unknown with any accuracy so you have to use a heuristic to guess the current % done.
For instance: when reading/writing/both many files of differing sizes on traditional drives there is an amount of latency per file which is significant and not always predictable. Whether you base progress on total size or number of files or some more complicated calc based on both, it will be inaccurate in most cases, sometimes badly so. Even when copying a single large file on a shared drive, or just on a dedicated system with multiple tasks running, the progress is inherently a bit random, the same for any network transfer. Worse are many database requests: you don't get any progress often because there is no progress output until the query processing is complete, and the last byte of the result might arrive in the same fraction of a second the first does¹. The same for network requests, though IE (at least as early as v3) and early versions of Edge did outright lie² there to try make themselves look faster than the competition.
The progress bars in videos are a different beast (ahem): the total time is absolutely known, any inaccuracy is either a deliberate lie or gross incompetence.
--------
[1] I once worked on a system that kept logs of certain types of query so it could display a guess of how long things were going to take and a progress bar to go with it, but this was actually more irritating to the users than no progress display as it would sometime jump from a few % directly to done or sit at 99% for ages (in the end the overly complicated guessing method was replaced by a simple spinner).
[2] It would creep up, getting as far as 80%, before the first byte of response is received. This also confused users who thought that something was actually happening when the action was in fact stalled and just going to time-out.