The following information is accurate as of the last time I played 1.3, i.e. early-to-mid 2022:

1. The autothrottle may or may not keep collecting input for its PID loop while the reactor is in manual mode - try giving it a few days to collect data before turning it back on, instead of immediately switching back to automated control after a fight.
   
2. The tooltip & label for the "SCRAM on solar flare" function are/were a bit misleading (looks like a forgotten typo from the process of splitting solar flares to their own distinct SCRAM mode to me).
   
   • If you have a solar-flare-shielding mod (e.g. Magnetic Shield), then it's safe to uncheck the second/rightmost SCRAM button. Leave the left one checked - it SCRAMs the reactor on loss of cooling (e.g. due to a tantruming pawn smashing the pipe).
     
   • if you don't have a flare-shield, then the SCRAM-on-flare mode should be left enabled to prevent a loss-of-control-logic meltdown. As with real-world nuclear plants, I usually design my RimAtomics plants with a separate plant-supply grid having its own RA step-down transformer, dedicated Rimefeller chemfuel generators (for black-starting the plant after a SCRAM), and isolated chemfuel supply.
     
3. If your power needs (machines, etc.) or non-dispatchable generator output (solar, wind) are highly variable, then the auto-throttle's PID loop tends to undershoot & deplete your batteries.
   
4. Conversely, the auto-throttle does not take the configured output limits of the transformers into account when chasing the setpoint - if all of the transformers feeding a power grid reach their maximum output before the grid breaks even, the auto-throttle will keep ramping up until it hits 100% flux or causes an over-temperature trip. This is especially common in multi-grid setups with wildly-disproportionate peak energy demand.
   
5. Dubwise has stated that RimAtomics tries to be as realistic as possible without becoming unplayable or violating ITAR restrictions. As such, it wouldn't surprise me if the auto-throttle interprets certain questionably-valid states as "a monitored control-system component has failed, SCRAM the unit NOW to prevent damage/protect the operators/comply with a license condition!"; this mirrors the behavior of a real-world unit, in which critical parts of the control system are supervised by non-overrideable safety systems that SCRAM the unit if a supervised component enters a fault state. Real-world units also have emergency-shutdown systems that can function in the total absence of electric power; some designs with non-pressurized rod channels use electromagnets to hold the rods to the service actuators & gravity for emergency insertion, while others use some sort of mechanical energy storage (hydraulic cylinder with a bucket of rocks on the piston, compressed air tanks, or even primary-loop steam) to drive the rods against the force exerted by the contents of the reactor pressure vessel.

Ultimately, I think that this "unexplained behavior" is really just a consequence of simplifying the UI for a reasonably-low common skill level; requiring the players to learn the finer points of nucleonics and control-systems theory to not melt their reactor would cross the line into "not fun" (and possibly "not ITAR compliant"), and adding control-flow tracking to allow the auto-throttle to retroactively justify its behavior (read: explain why it SCRAM'd a seemingly-healthy plant with no warning) to the user would add game-slowing overhead.

TL;DR there are a bunch of possible causes (most of which are to protect the reactor), and there isn't much "why did this happen?" info in the UI to avoid overloading the player with minutiae.