ArduPilot's ModeReason enum is the exhaustive list of on-board autonomous decisions: of 56 values, 43 are the aircraft deciding for itself, 21 of those because it detected something dangerous, and exactly one — SOARING_THERMAL_DETECTED — because it found an opportunity. As for end-to-end, PX4 mainline's mc_nn_control has a 10 KB tensor arena and a Kconfig default of n; ArduPilot mainline has none.
Flying a drone to 28 m in SITL and switching on the simulator's built-in GPS jamming, the flight controller declared EKF failure about seven seconds later, switched to LAND, landed and disarmed — it neither flew away nor crashed. Reading PX4's source then shows that of the 12 gates in EKF2_GPS_CHECK, bit 11, jamming detection, is off by default: the estimator catches jamming on its own, while spoofing can only be reported by the receiver.
After cloning and building both, three things differ from the stereotype: ArduPilot's EKF3 header credits the derivation to PX4/ecl, so the hardest layer is shared; PX4's last year of commits comes from company domains (380 from Auterion alone) while ArduPilot's comes from personal addresses with one contributor at 37%; and what really decides the choice is not performance but BSD-3 versus GPLv3, and which layer you need to modify.
PX4's own architecture docs say the companion computer runs Linux because 'Linux is a much better platform for general software development than NuttX; there are many more Linux developers.' That sentence is the entry point. The three transition paths differ sharply in friction — CV and MAVLink work on the companion computer transfers almost directly, flight controller firmware means learning RTOS and work-queue constraints, and estimation and control means quaternions and Kalman filters.