I think the overarching answer is that it is often too complex (or impossible) to calculate the amount of time it will take.
Sometimes it would just be a matter of crunching more computing time to better estimate the amount of work required (for instance, taking a better analysis of the files to be copied, or applying a more complex calculation to better estimate the number of steps needed to complete a simulation).
Other times it's rather quite indeterminate. When your system is installing a new program, it often has many dependencies to check are installed. And generally it doesn't have an idea of how long each one will take, and what dependencies those may in turn need. You may have all the dependencies installed already and it could take 30 seconds, or you may be lacking dozens and it takes hours. Hard to give a fair ballpark on that, especially when each situation will be unique.
Additionally, other drains on the system may change over time (due to what the user does... or background/scheduled processes).
Sometimes the estimate could be improved if the programmer would put a little more work into them. But then it's another reality that this probably isn't most developers' top concern, compared to furthering the actual productive tasks the application can accomplish.
In the end, right now, I believe it's quite often just a linear estimate -- a look at how many of the required basic tasks has the program completed. So it indeed tends to be a very rough estimate, and you should generally consider it as such going in.
A good analogy might be when you're reading a book.
And you decide you'd like an idea of how long it will take to finish the book...
You could check the page count and get a quick estimate based upon the pace so far.
It might be a bad estimate if you just started reading, because your speed might not be typical yet. But often it'd be a fair rough guess.
Or you could also skim the book, get a rough idea of how many pictures there are and the text spacing. And then have a better idea of what you face.
But it still may be a poor estimate if, for example, the text readability decreases, perhaps transitioning from simple to complex prose. Or the estimate may wind up way wrong because you failed to anticipate another task that will divert your attention.
You could get a great estimate by applying a big chunk of time to carefully analyze what remains in the book page by page, and could likewise improve it by checking your calendar and keeping a list of long-term past reading paces for various books.
But in the end, is the time it takes to do so worth the delay on just getting the book read?
We'd all love better indicators. But as is, we're probably going to have to make due with rough estimates, at least until computers as a whole start getting improved standardized algorithms, and being adept at "intelligently" weighing and anticipating dynamic factors (such as your ways)!
And the progress bar on that is maybe stuck at 5% right now. We'll just have to see how that goes 8-)