My comments on the FETs were mainly a reply for the "Please let me know if anything on it is confusing or looks incorrect."
"Sluggish" is of course relative, but consider the difference of running possibly amperes (just guessing on the basis of the chosen FET) of current over a non-insignificant channel resistance for 1 millisecond vs. perhaps 100 nanoseconds. Order of magnitude 10000x more power turned into heating the FET rather than getting to the load. It depends on the exact numbers and use cases whether that matters or not; there are cases where the FETs are deliberately used in that region of operation, with appropriate cooling. But typically in power switching use, the switching time is desired to be short (in the scale where milliseconds are considered very very slow).
The booster certainly makes the driving voltage (relative to "ground") higher, but so would a proper gate drive circuit, and it would do it faster, causing less expected load on the IO-pin, separate it better from unexpected loads, would be cheaper (well, those booster parts have already been bought, so no savings until they break for reason or another), and would actually work much better than the 5V drive in driving the gate. And weight less (well, grams, milligrams, but still).
With the last part of my reply, the "edit"-part, I was referring to the use of that N-channel FET, which, with its gate driven with 5V relative to "ground", has its actual gate voltage relative to its source. As the FET opens a bit, the igniter's Vcc may start going up (though I have no idea how quickly), which in turn makes the gate-to-source voltage smaller, so it doesn't necessarily ever see the 5V over gate-to-source as expected. I wonder, have you actually used oscilloscope to measure the gate to source voltage when turning the FET on in that circuit? (Note, not gate-to-ground voltage. And note, if trying to do that, if there are voltage spikes, the scope/probes will need to be able to handle them...)
A proper way to do high-side supply switching is to either drive the gate higher than supply voltage (charge pumps or such) with that FET type, or use a FET type and arrangement where the gate sits at the supply voltage (not at ground level) while closed, and another transistor is used to pull that gate down to ground to open the FET. The latter will give the full supply voltage for the gate, and does not depend on how the voltage changes on the igniter side.
Alternately, one could switch the low-side of the igniter instead, with that FET already used, but that may have its own design quirks to consider.
We have had no issues running it from the I/O pins in testing.
This is just hypothetical example, but...
Note, some issues do not show up immediately, causing problems that can combine with another event later. For example, a random occasional high-energy spike from a servo could at first break a protection diode for a IO-pin inside the SoC. The pin still works, no immediately detectable problems appeared. Some time later, since the protection diode isn't in proper shape any more, e.g. a random tiny ESD-spike from wherever could finish the job. Seemingly leading to explanation "No servos in use at the time, so that is not the problem", when in fact the servo was the main cause...
Or some kind of failure cascade. A real life example: a PC PSU had its standby 5V supply rail's first filter capacitor fail (slowly over time, the famous case of bad caps from far east). This caused its primary side components having to work harder, which they had definitely not been designed for (cheap design, working at near max even when everything is good), which in turn led to a current measurement resistor to fail (burn via overheating), which in turn caused currents to get too high for a zener, which thus broke, which in turn let the controller/switch chip see too high voltages... (I may recall some details wrong, been years.) The thing that looked to be the obvious "issue" was the severely burned resistor, but if one only looked at that, it would have lead to thinking of wrong original cause...
All that said, the reason may very well be something/anything else than so far considered here, too. I did spot a thread here about how a specific arrangement of code can lead to the user's Teensies breaking randomly later, but adding couple extra lines of code (merely adding a bit of delay in there) makes all good...