They are cheap, last 10 years with a single battery, and do only what they need to do. Also secure. No crazy attack vectors. And easily symbolically verifiable. And I wrote tons of simulators and fuzzers for them.
Stressfree qemu support was only for my even smaller avr targets, the 1281. But AVR is crazy compared to the Cortex-M4. We switched to arm completely, no avr's anymore. Anyway, no need for qemu or other emulators, when you can easily write simulators. You just throw in some mmaps, the simulated libc, the UART, and networking. Much better than emulators.
The key thing is to make the majority of the code portable enough to run on a PC. I find the best way to do that is to keep things data-oriented, using Plain Old Data type data structures and pure functions as much as possible. Alternative view: isolate out any device-specific pieces, like I/O into as small and simple pieces as possible. When one takes this mindset one realizes that even things that are considered as "device specific", like device drivers usually have a lot of logic that can actually be separate from the I/O. And by having a swappable I/O backend (say for I2C) one can actually test the vast majority of this logic on a computer. One should also have an implementation of the Hardware Abstraction Layer (HAL) that is "host", allowing to run on a PC, potentially with virtual inputs and outputs. This allows to run essentially all of the firmware on a PC. If one uses a embedded-friendly test framework, like Unity, then one can also run the same tests that is used on the PC on the device - to make sure that there is no difference when ran on host vs device.
Unfortunately, the code from embedded device vendors is rarely amenable to this, so that code can end up as "untestable" under this scheme. For them portability" is only considered between their own hardware devices, not to a computer. Then one has to trust that they have done their own QA. Which is usually not that great - looking at you ST HAL....
Okay, I'm going to ask "Compared to whom?"
Nordic has been one of the better BLE chip manufacturers in terms of documentation, in my experience.
Most places use Keil tools directly from ARM. So, if programming these sucks, so does programming most embedded Cortex M4 chips. (No argument. Keil sucks. However, that doesn't mean that Nordic sucks any worse than anybody else).
And now you can program Nordic chips using Visual Studio Code.
All told I figured out how to make a reasonably complex chain of bluetooth devices work (largely by reading the source and comparing against old version API documentation to figure out differences), so it definitely could have been worse. But to imply that just because the documentation is BETTER than the competition that it is GOOD?
No. Its fine.
They used to even ship a "No OS" SDK for the 8266, but the demand just wasn't there, FreeRTOS is pretty solid for the core competency of their product after all...
And you DO NOT have to use the Nordic SDK, there are lots of better and fully FOSS options — Apache Mynewt, libopencm3, Rust nrf-rs…
Also, it's not booting Linux at all. For these simplish one-purpose applications, you don't want the overhead and it probably would need more than the 24k or RAM onboard the nRF52810.
They could be using Zephyr though as it supports the Cortex M4 (it's a linux-like RTOS that can be heavily customised).
Embedded development is much different than what a lot of developers are used to.
In normal times, most products not marked as EOL would be available in tens of thousands with short lead times.