I think we should precisely differentiate three areas:
- There are bugs in the Mediatek MT7688, affecting SPI, I2S and I2C, see link in @György-Farkas' post above. If you blame Onion for using this chip, then please name a better one in the same price range having at least partially open specs. The MT7688 is nothing more than a slightly IoT-zed router chip. Its ethernet, USB, UART and WiFi hardware is solid, but its SPI was originally designed to connect the flash chip only, and things like PWM and I2C seem to have been added without much care. Sad, but certainly MediaTek's fault.
- There's not enough open documentation for the MT7688 to write solid drivers without a lot of try and error. As said, at least there is a publicly available datasheet (there was none for the Omega1's AR9331!), but it is little more than a list of register addresses and bits. No conceptual descriptions of any of the function blocks, very little context. So the drivers that exist in the open source LEDE stack have shortcomings just because the hardware is not documented properly. On the other hand, those developers who do have more information, are bound by NDAs so can't contribute to the open drivers, e.g. WiFi. This is the sad state of affairs around a only semi-open SoC chip.
- And then there's Onions strange way to (not) communicate all this properly to their users. It took an eternity until the LEDE build and uboot was opensourced, missing a lot of opportunity to get help from initially enthusiastic community members. And now, inexplicably, they don't respond to carefully collected information and hints like @Maximilian-Gerhardt 's excellent summary, and apparently don't update their firmware. IMHO, only that part is the real issue
Bottom line: there are compromises when building a $6 computer. You can argue Onion should have built another RPi instead for $30, but I am very happy they didn't, because once you know the limitations, the Omgea2 and Omega2S are fantastic devices to build small networked devices.
But Onion should actively communicate the pros and cons, admit problems, provide workarounds and quickly integrate work from others for the MT7688 into their firmware.
For example, this patch making hardware SPI usable by running it in half-duplex mode (full duplex is broken in MT7688 hardware).
As a side note: I am very curious to see how they will handle execution of the clock project - they'll need SPI for the display, probably I2S for sound, probably a ws2812 driver for the light bar. Sometimes developing a real application (vs. just cobbling together examples how to do cool stuff) helps improving the basics ;-)