No, you want to know if the command spewing out text is going to be done in about 5 seconds (I'll wait), 5 minutes (time for coffee or whatever) or 5 hours...
They also are there to indicate progress if no other visuals are present (no, it hasn't crashed yet).
Progress bars solve that given some uncertainty in most cases. And that is very much appreciated. Everyone knows or learns that they aren't perfect, and that is fine.
I was relatively deliberate with my wording. I'm not saying "get rid of progress bars", I'm saying they are bad at their job but we've never managed to really make any thing better.
Take your time estimation problem as the direct and obvious example: a progress bar on its own only really gives you a sense of timing if they move at a deliberate linear pace, which most can't do/promise (hence all the complaints about progress bars "stalling out at a percentage" when the system hits an outlier or discovers a lot more work to do), even then people are really bad at estimating linear speed of a progress bar. So a progress bar alone isn't great for judging speed.
Other threads around here make jokes about trying to add time estimates near progress bars as another way to indicate progress. Again, they work some of the time, but also need assumptions that for instance past speed predicts future speed that are often hard to guarantee in practice.
About the best progress bars can do is that "no it hasn't crashed yet" and spinners are generally better at that particular task (because progress bars don't have the granularity to show very small progression below 1/100th or 1/1000th or even 1/10000th of the overall workload), to the point that Windows added a spinner animation over top of its progress bars way back in Vista to make them better at the one job most users count on them for (for something of a best of both worlds, kind of, if you squint).
Progress bars solve problems, they just solve them badly, and yeah, that was the point of my message that we also haven't found anything much better. I agree with you that they aren't perfect and are mostly fine. We just sometimes need to admit that they are bad at their jobs and we'd replace them in a heartbeat if we actually found a better progress indicator of some sort.
To take things in a more constructive direction, that said, it is an area I've experimented with/tried to solve.
My big idea was radial progress indicators to try a different "best of both worlds" approach to progress spinners versus progress bars especially for "composite" progress indication where you have an unknown number of subtasks all running at their own speeds and can be discovered/initiated independently (such as downloading files). People are worse at estimating percentages of circles than lines, which I see as something of a benefit (because the exact progress percentage should be fuzzy).
It's still not great at giving an indication of overall speed/estimated time, but it's potentially very great at "the application hasn't crashed and is busy".
It was fun to experiment with/prototype, but I don't expect it to replace progress bars any time soon. (I think it should, but it's trade-off space where every option has drawbacks and while it fits closer to what I think is my personal "ideal", it probably won't make everyone happy either.)
Except 0/100 isn't a lot of granularity to indicate "still slowly working". (0/1000 or 0/10000 if you show percentages to the second or third decimal point aren't much better either, especially if the working set is in the millions or billions of things to do.)
I wasn't saying they didn't have their uses, just that they are generally poor at doing them. Though again we've also never really invented anything better. I'm not saying they aren't useful, just that they aren't great.
They also are there to indicate progress if no other visuals are present (no, it hasn't crashed yet).
Progress bars solve that given some uncertainty in most cases. And that is very much appreciated. Everyone knows or learns that they aren't perfect, and that is fine.