Looking more into this, the SET_MODE message is deprecated, and shouldn’t be used anymore. The new approach uses the MAV_CMD_DO_SET_MODE command instead (which is what is sent by master.set_mode(mode_id)), so the acknowledged command check should be for mavutil.mavlink.MAV_CMD_DO_SET_MODE.
I’m unsure whether this is actually what’s causing your issue(s), but without looking further into ArduSub’s codebase my understanding is it’s at least possible.
Pixhawk 2.4.8 is known to use some cheap hardware components, so may not be super reliable, but this performance issue seems to be in software (manual mode shouldn’t allow the outputs to change without the commanded motion changing), so I don’t expect that’s the cause of the problem here.
That said, if the set_mode change doesn’t fix it then I’m pretty much out of other ideas…