There's a difference between 'bogus' and 'an estimate that's subject to change'. Personally, though, if I were the designer of that dialog, rather than estimating time to completion based on ( amount remaining / current speed ), I'd do it based on ( amount remaining / average speed so far ). As you get farther along, that reduces how much a short slowdown (or speedup) will change the estimate. At the same time, with the graph being shown, the user can see if the speed drops to zero and stays there for a considerable time, so even if that happens at 99% completion, they can set their own criteria for "how long am I going to wait with zero progress before I decide this thing's frozen and kill it".
To me, that last bit is the big thing that's missing from most progress dialogs right now. I want to be able to tell if progress has stopped, and for how long it's been stopped. If you just show percentage completed and time, I as a user can't tell whether progress has slowed down to a crawl, or whether no progress at all is being made. Further, without the historical information provided by the graph, If I want to tell whether, say, the bar moves at all in the space of five minutes, I often have to resort to tricks like taking a Post-It and putting it on the screen where the bar ends right now, then using that later to tell whether the bar has moved. (A percentage count helps with this, but generally, the percentage count seems to be rounded to the nearest 1%, while the bar has more than 100 divisions and seems to be using them. Thus, a single pixel of movement might be only 0.3% progress, which might not show up in the percentage count, if it's not showing that same degree of accuracy.)