The point is that studies back up the requested priorities/interests of the users. You stopped at the word "goal" without reading the rest of the sentence. (ETA: Also from a pure syntax diagramming perspective, that parenthetical was tied to "my understanding" not "the goal".)
To make my early point more explicit: average users don't care about Progress Bars with exact percentages and to the second/millisecond estimate times. Users want Progress Indicators that tell them the app hasn't crashed, is busy, and is busy with something relevant.
Progress Bars in general are just a bad way to tell users the information they want, whether they "lie" or not. I agree that in the case of an unrecoverable crash, an application should no longer show a progress indicator. I agree that users dislike it when an app suggests something will take less time than it does, but I think "build better estimates" is a Halting Problem trap and I think the answer has to be "show fewer estimates" and "build intentionally worse estimates". "32.5%" and "ETA: 3:21:59" shows far more implied accuracy that any system can actually deliver on than "Fooing the bar" and "This may take a couple hours" do.
The point is that it isn't "lies" versus "Truth", but "uncertainties" versus "implied lies". The application is always likely uncertain how much time things will exactly take, that's the nature of software (and the vagaries of hardware/internet conditions/weather, plus the Halting Problem). Specific percentages and too accurate estimates lie in their own way that the tasks being taken are all fungible and exactly linear in time/space, that the possible error bars are in parts of a percent and seconds rather than tens of percent and minutes or hours. There's always going to be "implied lies" in a progress bar, the question in this article, this thread, and others is how do you present how much that "you don't yet know" to the user that doesn't give them the wrong impression?
Again, developers certainly care about the raw percentage of work done or the raw estimate down to the actual second, but those sorts of details do more harm to the user's value of the system than good. They sometimes think they want to know those raw scores, but those raw scores don't actually tell them what they want to know or what they need to know. It's not a "lie" to just not give those raw data to the user. It's sometimes more of a "lie" to give that raw data to the user and then frustrate the user that the last 1% is different from the first 1%, that the exact-to-the-second ETA was wrong by hours.
Progress Bars are one of the best Progress Indicators we have, but they aren't perfect and they confuse and frustrate users sometimes as much as they help.