Let it crash is an engineering design for systems large enough that statistically unlikely failures occur regularly. Like a data center or the original use case, telephone switch centers.
Even if let it crash worked, it seems philosophically inappropriate for a drone controller.
Not at all, "let it crash" is simply a way of phrasing "consider reset in your flow of control".
In embedded systems, certainly safety-critical ones, you have to consider the possibility of a reset path at all points in your flow of control. Your code resetting is a valid flow of control.
This is absolutely necessary to get a properly robust system.
Your drone system needs to be able to handle a reset at any point and still maintain adequate control of the aircraft. This is "Let it crash".
"Let it crash" is essentially the same thing. Take account of the necessity of reset, because you can't stop it happening.
Yeah; the basic philosophy of 'let it crash' presumes that the issue is bad internal state, and you need to get back into a known good state. If your domain doesn't really have a way to get back to a known good state, or a way to determine a state is good and persist it, it's not going to help you.
I see no incompatibility with a drone controller if you have enough redundancy or can restart services fast enough for it to not be a problem (probably 1 second is still ok).
What is completely incompatible with disposable workers is complex numeric processing. Unless you can segment it with small non-communicating unities, of course. That's the kind of application that asks for a low level language.
Even if let it crash worked, it seems philosophically inappropriate for a drone controller.