No. Different issues.
Drift is likely the result of lower prioritisation in the real time threading, relative to other tasks deemed more vital, yielding slightly inconsistent results on playback. Think about the pref in your Audio Device labeled “Audio Priority - Normal/Boost”. Cubase has to have a heirarchy of what matters most in realtime and some things have to give. Automation capture/playback is one of those, apparently.
Latency compensation for automation is no different in principle than for plugins. Simply automatic, user transparent, adjustment for the variable processing time for audio throughput based on a number of variables, mostly plugins. In this case, it seems that a change in buffer size of the soundcard does not produce a corollary change in the playback timing of automation data, creating an offset relative to the initial accuracy. That also means that as the max latency in the plugin paths increases as plugins are added, that is not accounted for in automation playback either. That factor probably goes unnoticed by most testers.
“Sample accurate” only refers to the frequency (or granularity) of automation recording and playback. Drift and Latency could both be perfect or flawed independently of the frequency (and therefore the amount of data) of capture of automation data. If Drift and Latency are both corrected, timing interval of the automation data capture would be adequate at much less than the full audio sample rate.
We don’t need an automation data point for every audio sample. We just need the automation data to be accurately compensated for latency variables and also 100% consistent in playback timing. Just 1% of the sample rate at 48K would give you 2ms accuracy. Sample rate is not the issue. Latency Compensation and Drift are.