I would have probably recommended Android myself if I had been involved. The points you raise are valid, but:
1. You're going to have way better board/vendor support with Android.
2. The Android networking stack is more featureful than any RTOS. You aren't constrained with e.g. TLS support or paying a vendor $$$$ to implement what the infra team wants.
3. You can hire Android developers by the dozen. RTOS application developers are much more annoying to hire, even if they'll work for cheaper.
4. You don't have to pay a vendor (or build it yourself) to get basic platform functionality like A/B updates, a build system, secure boot, etc. Android has solutions for these of admittedly varying quality.
But you'd also get all of this and more by skipping the hardware entirely and just selling the app.
If the main goal is vendor support, Android is downright awful compared to Linux when it comes to embedded use cases.
You can get up to date Linux versions for pretty ancient stuff, but AOSP does zero favors for porting and vendors are more than happy to throw their hands up and leave you fending for yourself, breaking lots of stuff (like the build system) along the way
...but they also raised $30M and landed an extra $10M in their first week of preorders. Between that and the heat behind their name, they weren't hurting for cheap labor.
I think you're ascribing too much intention to their choices, this device feels like they raised a bunch of money, let everyone do their own thing and dumped the result over the wall.
Good mainline linux support has not been my experience for the kinds of mobile SOCs the Rabbit was inevitably going to be using. Taking a look at the PostmarketOS support page for the mediatek SOC used in the product [0], seems like most of the sleep and radio drivers are not mainlined/supported. Yes, Qualcomm and mediatek drop support after annoyingly few years, but they do provide support before EOL.
Haven't mentioning mainline support at all, and I'm speaking relative to Android: vendors that do Linux poorly do Android even more poorly
And I wouldn't say that these vendors blanket provide support before EoL. I work on a product where EoL is a very long time due to automotive involvement. The vendor's standard of support is extremely low, with most requests resulting in being pointed to some "partner" which is usually a ragtag team of contractors well versed in some set hacky fixes for the vendor's boards
Your goals when selecting an RTOS are usually development-centric, not to provide product level features. What did you have in mind that the OS should be bringing to the product?
What? There's no reason but product level features to choose an RTOS. An RTOS won't be more ergonomic, won't make life easier in general, won't give you any new primitives that are development related...
You choose it because the product demands good performance, low latency, etc. And the Rabbit fits that bill pretty cleanly.
Closer to bare metal doesn't mean it needed to be running a custom GPU driver, but it's also not running a Flutter/Compose app on a 6 year old GPU core...
Typo, didn't realize I wrote "RTOS" out of habit instead of "OS".
Regardless, I wouldn't consider those product level features and I also wouldn't consider them strictly limited to RTOSes either. A normal operating system is going to be significantly better for performance on good hardware, which is why all of the top supercomputers are running a variant of Linux. An RTOS may give you lower latency, but it's really specialized to realtime as I'm certain you're aware.
You choose an RTOS because you either have those realtime constraints, you want a "smaller" system, or you're running hardware that can't support a full-fat operating system (e.g. ESP32) and the RTOS offerings are what's most convenient. I don't think any of those apply to the Rabbit device in a realistic way. Implementing it in an RTOS wouldn't speed up the server-side inference that's doing the actual work here, for example. Since there aren't reasons to go with an RTOS, your criteria for OS selection are going to lean towards the meaningful benefits a normal OS like Android offers, both in terms of development tooling and board support.
1. You're going to have way better board/vendor support with Android.
2. The Android networking stack is more featureful than any RTOS. You aren't constrained with e.g. TLS support or paying a vendor $$$$ to implement what the infra team wants.
3. You can hire Android developers by the dozen. RTOS application developers are much more annoying to hire, even if they'll work for cheaper.
4. You don't have to pay a vendor (or build it yourself) to get basic platform functionality like A/B updates, a build system, secure boot, etc. Android has solutions for these of admittedly varying quality.
But you'd also get all of this and more by skipping the hardware entirely and just selling the app.