I had noticed the same thing and had sent direct email to them about it some months ago. Like you, sometime between v1.3 and v1.5, something caused my guide error (RST-135 mount) to virtually double. I made that as clear as possible to them (all the way up the chain of command).
The answer I got from them was "We changed nothing." I don't know if we ever will get an admission that there is a bug in ASIAIR guiding.
What I have noticed so far is that the current guiding appears to need very clean image frames. You pretty much have to saturate the stars (never a good idea for determining centroids) to avoid star mass loss. You also need very long focal length guide scopes (or an OAG) to overcome the lack of MinMo adjustment.
When I ran my mount simulator, which projects the stars at the mount coordinates to an iPad screen, with a ASI174 pointed to the iPad as the "guide camera." I can get very solid guiding -- but that is with artificially drawn anti-aliased stars on a solid black background, so very good signal to noise ratio. With the lack of mechanical errors from the simulator, I could get RMS errors of the order of 0.1 arc seconds.
My current conjecture is that something with the guide camera image acquisition has changed to cause the signal to noise ratio to worsen.
The frequent star losses are just one of the more extreme manifestation.
Something is very wrong with getting a clean centroid to guide on. Who knows, perhaps they changed the bit depth (to shave some milliseconds on the precious Raspberry Pi), or change the default bias, or applied some silly short cuts without understanding the autoguiding pipeline. Or even sending a bad image sequence to PHD2 (for example, if they did not flush the image pipeline and end up submitting extra pre-corrected images to PHD2).
Chen
