You get to write device drivers and dig into the OS internals. There is even a port of the uIP TCP/IP stack that can be used with development boards such as the Nucleo-144.
I did some contributions to RIOT-OS [1]. Honestly it was nightmare to me because they have strict policies not allowing manufacturer drivers so I should write peripheral registers directly, which leads to a lot of bugs that is hard to debug.
In particular, I get really nervous about scenarios where multiple low level peripherals needs to cooperate to get something to happen— thinking about something like having a DMA drive a timer to piano-play oddball serial protocols like the WS2812 one. That's enough of a nightmare in bare metal where you have total control over all the registers; I have trouble imagining an OS abstraction layer which wouldn't make it considerably worse.
Writing a simple driver for say an I2C sensor is quite doable. However, getting a driver into mainline requires conformity both in terms of licensing and in terms of coding standards for the whole library, including 3rd party code.
It was pretty much about their coding standards. I had that experience because I was contributing for mainline branch. They think avoiding abstracted manufacturer peripheral libraries (like STM32 HAL) is the best way to keep the binary small. It is pretty much appose to what Zephyr OS is doing.
I think peripheral libraries are adopting BSD license these days so the license shouldn't be an issue these days.