If you have enough ACKs going upstream to start being a problem, you are most likely downloading a large file, and that traffic isn't particularly latency-sensitive in either direction. If you have something actually interactive that's also trying to use the same link (eg. VoIP), that traffic probably should be prioritized over a firehose of ACKs even if it will make the file download a bit slower. ACKs shouldn't be treated as any more important than the payload data they they are acknowledging. Low priority downloads should generate low-priority ACKs.
ACKs are generally so small its irrelevant, unless your bandwidth is ridiculously asymmetric (less than a 23:1 ratio 64B ACK vs 1500B packet) which even really crappy cable providers don't do.
It's a very real problem for many if not most surviving DSL connections. Cable has gotten a bit better in recent years, but 10:1 is still about the best you can normally expect, and 20:1 or 25:1 is still common for some of the higher speed tiers on cable. So ACKs can realistically be expected to take up half of your upstream bandwidth on common connection types. That's far from irrelevant unless you never transmit anything other than ACKs and HTTP GETs.
I am neither arguing for or against, just that delayed ACK probably isn't the only reason for the connection to become sluggish. A typical page makes dozens of requests, these are packets to be uploaded, if the uplink is saturated, the latency should increase, I'd expect that to affect the time it takes to render the page.
