I'm wondering if its a temporary blip. I guess we'll see how it goes for the rest of the day. It was an odd time for it to start shooting up the download ES. When it used to jump up ages ago it used to be around 4pm. But this all happened in the middle of the afternoon.
Some of this depends on your starting point.
In your case, you have been through DLM intervention, so FEC and interleaving has been applied - and you seem to suffer (from that one set of stats) from a high proportion of RSCorr relative to the RS count. In english, that means a lot of blocks have been corrupted - about 5% of the total sent downstream - but have been fixed by the error correction mechanism. Because they've been fixed, they don't contribute to the ES counter. However, the sheer number of RScorr tells me that your line is suffering from a fair level of noise, and that DLM probably needed to intervene.
The RSUncorr counter tells us that for every 100 corrupted blocks that gets fixed, roughly 1 block is unfixable. These failures contribute to the CRC counter (aka OHFerr), and in turn affect the ES count. The fact that 5% of the RS data blocks become corrupted, but only 1% of the corrupted ones goes unfixed, tells me that the FEC settings are working - they are giving you a stable line. ES levels of 60ish are quite low; my old line would get 600-800 per day (though DLM hadn't intervened).
You ask about why your ES count rate has increased, and I'd point straight to the number of RScorr and RSuncorr going on. You've been tracking the ES value, but having you been tracking the other parameters too? Those might show any underlying problem, such as whether the noise increases overnight or during the day.
Ultimately, it is the way that several parameters need to be tracked that makes programs like BaldEagle's HG612 Modem Stats useful - the graphs give a feel for dependencies.