I think you may be
1) oversimplifying the design,
2) underestimating the rationale that went into that decision.
Obviously possible.
The software engineering analog here would be "I'll just leave myself this root account open so I can log in afterwards if something needs fixing." To get to that point, I don't see how you can know
that much without realizing how bad an idea that is. Yet, it is a persistent pattern in massive breaches of internet-enabled appliances that we just cannot seem to get rid of. And I'm not talking only about the no-name cheapies; the clients of the name-brand netword equipment manufacturer Cisco seem to get bitten by this same thing every decade or so at least, even though many consider them the go-to enterprise source for such stuff.
I personally know enough of Arduino, BLDC motors, IMUs, various wireless comms and such, to consider tackling the task of building such a drone purely from a hobbyist basis, without being any kind of an engineer. And I'm known for recklessly tackling stuff that ought to be obviously too big to bite. But even if on mind-altering drugs, I would never ever make some of the design choices the designers of that drone did, unless I did those choices deliberately. So that is my yard-stick. Perhaps it is utterly, utterly wrong. I have no way to know for sure, just wanted you to know
why I believe so –– what I believe is uninteresting, but the reasons
why may be of interest and perhaps use to others.
That said, having done so much network service programming (a lot of web stuff, but plain 'ol TCP/IP, and more relevant to this particular stuff here, plenty of UDP/IP stuff too). UDP/IP in particular has the same kind of problems a remotely operated vehicle has: routers are free to drop UDP packets whenever they deem it necessary, so unlike TCP/IP, UDP/IP has no guarantees or features to provide any kind of reliability for the messages.
I guess having had to learn that the hard way over two decades ago, has colored my opinion of how reliable (rather, unreliable) real-world communications are. I am completely used to the idea of having messages lost and connections close mid-stream; and always plan well ahead how to deal with that. You could say it is one of the "details" I think about a lot when coming up with a design.
As an example, I would never use the same kind of control protocol to a remotely operated device as USB keyboards use. (Three types of messages are sent for each "keypress": a "press" event, optionally some "autorepeat" events at specific intervals if the key is being depressed for a sufficient duration, and a "release" event.) Instead, each control message would always contain a limit to its application – for example, "go
that way at rate
this, but stop doing that after duration
then unless I direct otherwise" – because I've had even USB keyboard keys get stuck on systems that occasionally silently drop USB packets. Using UDP/IP, that sort of issue would be basically guaranteed to occur often enough to be noticeable to everyone. (And that assumes you've already learned to develop UDP/IP in a lossy test network. Because real world networks do not behave like the nice small closed test network you set up for testing; and you'd find that out the first time you used your stuff in the real world. Real world is a hard, effective teacher.)
So, indeed, I do need to re-evaluate my view on what one can expect from Arduino hobbyists; I admit my yard stick seems to be pretty bent. A banana.
God dammit, I'm measuring in bananas again.2) Safety target is not even near to 100%; accidents are to be minimized within resource constraints; but resources can't be increased.
Drop that to say 50%, and I'm inclined to agree.
Still, I must point out that in my view/terminology, reducing safety target that low because of
fiscal resource constraints, is still malice. It's not like the resources they were running out was energy or room or capability or such, just "business value".
So Arduino is related; it was a project made by total hobbyists who can't take such a responsibility.
Yes; similar to how some people buy a gun and end up shooting themselves in the foot, or a biker they thought was a moose. Not malice, no, but negligence, perhaps?
It is not the existence of the tool or Arduino at fault, because this type of people end up doing much the same even if all they have are a bunch of rocks and a small satchel.
Some people say it is important to limit the access to such tools, but I disagree: I believe it is much better to just severely punish the idiots who misuse such tools. Kids and teens do get a pass, being still the responsibility of their legal guardians; so if they do it, punish their legal guardians instead. (I learned that from Robert A. Heinlein.)