One of the biggest challenges will be drivers for the actual hardware - at the moment it looks like they have support for SPI and for built in LEDs. But it's a big challenge to expose all the different peripherals that come with MCUs in a consistent way.
Actually, looks like they've got quite a lot of stuff done already:
With MicroPython you can have C drivers and just do the MicroPython bindings. I do not see the benefits of having yet another interpreted IoT language and it does not make sense to do the drivers in the interpreted language itself.
The consequences of a type unsoundness in TypeScript are typically much more benign (an exception typically) than in C (a buffer overflow, arbitrary code execution, etc.). Also the application logic is more visible in TypeScript just due to it being higher-level - there isn't so much low-level detail (ever done JSON in C?) so less chance for a mistake.
I wouldn't say zephyr has "tons" of drivers, except maybe in comparison to other RTOSes. It has a few drivers for each of the device types you might use, but you can't just buy random hardware without checking support the way you can with Linux. There's enough that you have examples for implementing your own drivers pretty easily though.
I agree with your driver assessment as someone who's used Zephyr quite a bit. If you're working with a new sensor, writing a new one is super straightforward. I don't have much experience picking sensor devices for embedded Linux, but I didn't think they had a ton of drivers for those types of devices. Bluetooth, networking, and SoCs, sure, but not so much for I2C/SPI sensors and displays and whatnot.
Tons might be stretching it. But to my knowledge there are not many alternatives for microcontrollers that have more?
Hopefully one day it will be like Linux. At least they are trying to tackle the driver problem, unlike other most other RTOSes.