Google is developing an OS called “Fuchsia,” runs on All the Things (Android Police)

You're always going to get trouble with contention over things like memory bandwidth and thermal budget. You need a lot of bandwidth to render a fancy 3D UI, and a lot of bandwidth to encode a high-res video, and to run the user's favourite CPU benchmarking app, and to Miracast the display over the wifi network, etc, and they all generate heat too - and the user might want to run any combination of those features simultaneously.

If you wanted hard-real-time guarantees that all of those features would run with perfect performance and never miss a deadline, even when all turned on at once, you'd have to massively overprovision the hardware, making it expensive and power-hungry. Alternatively you could choose hardware for the expected 'reasonable' use cases, design everything to cope sensibly with failures to meet performance targets (e.g. cleanly dropping frames), have some QoS mechanism to keep everything reasonably balanced so one feature doesn't get completely starved, and design the UI to generally keep the user within the set of reasonable use cases (e.g. don't allow multiple arbitrary apps on screen at once). The second approach seems more sensible for non-safety-critical feature-rich devices like phones.

>> RTOS means that it's deterministic.

Depends who you talk to - from what I've seen in the context of mobile SoCs and IoT, nobody ever means hard real-time, they just use "RTOS" to mean any lightweight OS (as in, a few tens of thousand of lines of code that provide threads and mutexes and interrupt handlers and a memory allocator and probably not very much else). That works okay for soft real-time requirements because the OS stays out of the application's way, and because there's only a single application and it's usually only responsible for a fairly small and predictable set of features (since the SoCs usually contain multiple small processors all running their own independent RTOS instances).