I was trying to think why real world performance doesn't follow that theory.
My one piece of good real-world experience came from my first FTTC line. On day 1, it synced at full speed, but encountered about 4% packet loss, permanently. Throughput tests (speed tests, downloads etc) came out with a speed of about 2-3Mbps lower than it ought to.
48 hours later, DLM intervened with standard FEC and interleaving settings, and solved the packet loss. IIRC, that knocked the sync speed down by 2.5Mbps. Those throughput speeds ... stayed the same..
As luck had it, the line needed to be regraded the next day, to change upstream from 2Mbps to 10Mbps. This entailed a DLM reset, so the line went through this exact pattern a second time.
It seems like everyone is just trotting out the standard theory which states some tiny number of errors will be horrifically bad.
Quite a lot of web based streaming can also be done over TCP, many sites will have a range of different protocols available, pre-recorded video often uses RTMP (TCP) or just HTTP.
My comment on video quality was focussed on the type of video BT cares about: their multicast TV service, where they need a quality that competes with Sky & VM. I'm sure they don't care about YouTube really, but catch up services are probably thought of quite highly now. This probably does help focus their minds nowadays.
Older ADSL DLM mechanisms were probably more focussed on keeping stable lines, reducing "truck rolls" as the Americans would put it.
The trouble is, the DLM will take action against ES counts that have minimal impact on web browsing or even bulk downloads.
The trouble is that DLM cannot distinguish what impact an ES count means, because it has no way to correlate it with a higher level. It could be highly significant, of little importance, or have no effect whatsoever.
BT are conservative, so will tend to err towards the "highly significant" more than otherwise.
Another anomaly is that it appears the targets are absolute error counts per unit time. So slowing the line down may reduce those counts down to with acceptable values, while leaving the percentage data loss and therefore number of retransmissions unchanged.
Aren't the targets more about "time in error" per unit time? The use of "ES" takes away the dependency on the absolute error count, and turns monitoring into a study of how many bursts of errors occurred rather than absolute error.
IIRC, a burst of errors is likely to create one batch of TCP retransmissions, so the two correlate. I think it would be very hard to eradicate most ESs but keep the same volume of data loss.