Occam is your friend. I have seen plenty of seemingly distorted progress bars, and I am pretty well convinced that the vast majority are not deliberately distorted, but rather distorted due to either lack of information or laziness.
There are two different types of progress bars that I typically see, with different problems:
Upload/Download/Display
File Upload - Upload speeds are often much lower than download speeds due to the speed of the user's internet connection (e.g., DSL is typically asymmetric with upload 4 (or sometimes more) x as fast as downloads) and/or due to the speed of the server. It tends to be easier to spread out the download process to multiple servers (mirrors, CDN, etc.) than uploads (which are often limited to one server for security reasons). These bars are generally quite reliable except: (a) at the beginning they may have an arbitrary (and therefore inaccurate) chunk (5%? 10%?) for "getting things started, (b) the actual upload process may slow down at various points due to factors beyond server control but the progress will continue based on a simple calculation of the file size and (c) there may be an extra delay at the end (e.g., "stuck" at 99% or 100%) as the server does post-upload processing (virus checking, database operations, etc.) of the file.
File Download
Most file downloads are small enough (even up to several megabytes) that the server will simply let the browser handle the details, in which case any progress bar will be based purely on file size and any abnormalities due to internet access speed/problems, generally beyond server control. However, some systems will provide a progress bar similar to the typical Upload progress bar and with the same 3 caveats as listed above, though in this case the last issue at 99%/100% is dependent on the user's computer instead of the server.
File Display
This includes charts and complex reports/pages. The progress here is typically due to server-side processing, which is under control of the server. However, that processing may be very "chunky" or subject to delays from other processes (e.g., request from other users). Often the progress will be broken up in a reasonable but arbitrary manner which may match the average report but not exactly match any actual report.
For example, the programmer might measure 100 reports and find that, on average, 15% is used for an initial big database query, 40% is used for looping through the data and analyzing it and 35% is used for another process that takes the processed data and generates a chart image.
The first problem is that the numbers may vary considerably depending on the particulars of the user's data selection.
The second problem is that some sections may not be easily divided. For example, the database query might be an atomic process from the perspective of the main program which makes one single huge complex SQL query and waits for the results. So the progress will go from 0% to 1% and then pause for a relatively long time before jumping to 16%.
The third problem is that some sections may be easily divisible but not consistently divisible. This report that takes 40% for the main processing loop might have 1,000 primary records - which would equal 25 records per % of total progress bar. However, it might turn out that some of those records take 1 millisecond and some take 1 second, and the result is a "jumpy" progress bar.
User-Driven Function "Progress"
This is my terminology for progress bars that are based primarily on user events rather than server processing. Two typical examples are surveys and complex forms:
Surveys
In order to encourage completion, a survey will often show a progress bar with it incrementing a little bit on every page. These are actually fairly reliable, in my experience. The exceptions are branches. A survey might have 20 pages, with 5% progress per page. But if there is a point in the middle where based on one answer either the survey is cut short or the survey is extended then the progress bar will either "jump" a large chunk or seem to "slow down" - i.e., all of a sudden instead of 5% per page it is 2% per page because more questions have been added. This is not deliberate messing with the user's minds, it is simply inability to predict the exact progress speed in advance.
Complex Forms
A complex form might have 8 pages - 12.5% per page. However, some pages may be really easy (e.g., name/address/etc.) and some quite complex (e.g., medical details or descriptive note fields). The progress, thanks to lazy programmers (like me) may be based on the number of pages without adjusting for the complexity - and therefore the time - that each page requires to complete.
