answering with a simple cross-multiplication is awfully condescending I think, I'm sure that he already knew that, it's how we constantly guesstimate things in our head too.
The problem with file-operation progress bars is that it's only correct for uniform data, so if you copy 100 files that have all the same size and your drive is doing nothing else, the estimated progress will be spot on, but what if the first 99 files were small txt-files and the last one is a large video file? The progress will be WAY off.
This problem is further increased when you're not handling files in one folder, but multiple sub folders. Say you have 5 subfolders and you want to delete them (size doesn't matter much in this case then), the first 4 folders only contain less then 10 files, so by the time the operation comes to the 5th folder it thinks it's about 80% done, and boom 5th folder contains 5000 files and your progress jumps back to 1%
WinXP tried to get around this by counting the number of files beforehand which meant that when the folder wasn't indexed in windows, depending on the number of files, XP didn't really start the operation for the first 20seconds (time it took to count) which made everybody furious.
So while I also don't have special knowledge on how Windows does it (but what else is there apart from counting files and bytes) I hope I could illustrate why it's flawed and why it never will be perfect.
Best you could do would be to not rely solely on filecount OR bytecount, but build an average out of the two.
Or if you wanted to go extra crazy the OS could start a database of how long these operations took in the past on your machine and factor that into the equation.
Final thought: If someone would think of a filesystem that would let the OS know what size every folder has, without calculating it first, you would at least get a correct progress estimation when deleting whole folders and not just parts of it.