Indeed, this is a bad idea.
A complex Linux system with many undocumented corners and unresolved bugs is the last thing you'd want for a flight computer. In the case of the Omega 2+ even simply compared to other boards with the MT7688 chip, there's also the issue that an error in the choice of the companion flash chip on the module means that if the MT7688 experiences an unprepared reboot (for example from a glitch, or a watchdog) without the flash chip power cycling, a disagreement of addressing mode means that it will hang and be unable to boot.
Actual flight controllers are quite simple computers. A few years ago they were typically 8-bit ATmegas or STM8's, though fortunately that era is now in the past. Today they are typically simple ARM Cortex M0, M1, or M3 parts, from the likes of STM, Gigadevices, Nuvoton, or Asia-only vendors relatively unknown in the west. These run with internal flash and ram and have the rich I/O that @ccs-hello mentioned. For these purposes they run simple main-loop style bare metal firmware, drastically simpler and more responsive than what you would get from a multithreaded architecture. If you're interested in experimenting with this the realm of tiny featherweight platforms, there are a number of published open source replacement firmwares for toys like the H8mini, CX10, etc - ironically, the smaller (and therefore twitchier) the aircraft, the faster the control system needs to be.
If you do choose to fly a system like the Omega 2+, it should be limited to optional features, for example, you might use it to log data that you'd like to have, but the loss of which would not cause the aircraft to crash.