That issue is: bandwidth. If I’m in a place / on a device that has super slow internet, I’d love to be served a very light web page so browsing is still acceptably fast. If I’m in a place / on a device that has super fast internet, by all means ratchet it up and deliver me more.
My problem with bandwidth detection is that it will never be really accurate. In its simplest case the browser would just send the speed of the network the user is currently on. However, I can be on 3G but since I am also currently updating a dozen of iPhone Apps, I don’t really can surf using 3G speed. If the browser wants to detect the real bandwidth I currently have, it would need to download some Megabytes and measure how long it takes. Since my available bandwidth can change quite often, he would need to repeat this on a regular basis. Thus it would use a quite big amount of my network just to detect my bandwidth.
This seems to be a lot of work for a feature I can’t come up with a single use case where this would be absolutely necessary. I still need to detect the screen size and ratio (has the device a retina display?) in order to provide the browser with the correct image. Of course I would be able to serve, for example, two different versions to mobile clients. One JPEG with 60% compression if the user is on a slow connection and one with 90% compression if the user is on a fast network. However I am quite sure that only a small minority of web developers will go through the trouble creating even more different versions of an image. If only very few web developers would use this feature, it seems like a bit of overkill to detect the real bandwidth (and therefore use up my monthly download limit) just to improve the quality of these few sites.