Not complaining, but what could have caused insufficient instability for this to happen so quickly?
So quickly? I'm not sure that 4 years counts as quick.
The answer is likely to be crosstalk - which is noise cause by the signal of other FTTC subscribers. VDSL2 is very susceptible to this, potentially losing up to half of your theoretical speed.
The extra noise from crosstalk normally manifests itself in two ways, with a consequential third.
1) The increased noise makes for a decreased SNR - so reducing the maximum attainable speed on your line. For those over 80Mbps, this happens (mostly) invisibly for a while. For those with lines longer than, say, 200-300m, crosstalk can become enough for speeds to drop below 80Mbps.
2) Increases in noise also come with increases in the errors (visible as the count of CRCs), and therefore the average error rate (visible as the ES count over 24 hours). Such errors become glitches on streamed video and audio, or triggers re-transmission of parts of download - which also acts as an intrinsic method for slowing down the TCP protocol. This means downloads are slowed down.
In some cases, packet loss can be seen in a BQM, but smart router queuing mechanisms can mean that packet loss gets focussed on TCP rather than the UDP used by the firebrick. This means slowdowns would not be so visible on a BQM.
3) When the error levels in (2) reach a sufficient threshold, DLM kicks in. It is likely to have been a one-off, at first, so will recover. Over time, the error rate would increase to breach the threshold more often until, eventually, DLM stays triggered.
4 years is plenty of time for take-up to increase, and for you to have been experiencing all 3 of these issues.
With luck, G.INP will be around soon to reduce the impact of DLM intervention. And with more luck, vectoring will arrive eventually so that the error rate drops and the attainable speed is restored.