And there is nothing stopping you from taking the original GPL'd FreeRTOS codebase and merging in all of the MIT licensed improvements. If you make a better FreeRTOS, that's what people will use.
I've seen this happen many times in open source. For example, to this day LGPL's LibreOffice, which started as a fork of OpenOffice, reviews all OpenOffice patches and cherry picks the good ones.[1] On the other hand, Apache OpenOffice can't benefit from any of LibreOffice's patches.
Viral licenses like GPL have an edge and will win out if there is a community that actually cares.
GPL licenses tend to discourage adoption due to their onerous restrictions, which is why most projects today choose anything other than the GPL family of licenses.
The virality of GPL actually results in most companies explicitly banning the use of GPL tools and code to prevent the GPL from "infecting" their own code.
For what it's worth, LibreOffice is probably LGPL because of OpenOffice's history with the Oracle buy-out. Oracle gave OpenOffice to Apache for the same reason Google gave Wave to Apache: They run a sort-of paliative service for software projects.
Their "fork" is additional libraries for FreeRTOS specifically for IoT kind of stuff packaged into the kernel. Not everyone needs an Amazon version of the FreeRTOS and most users wouldn't want extra junk in the kernel considering the kind of hardware that an RTOS is meant to be run on.
I've seen this happen many times in open source. For example, to this day LGPL's LibreOffice, which started as a fork of OpenOffice, reviews all OpenOffice patches and cherry picks the good ones.[1] On the other hand, Apache OpenOffice can't benefit from any of LibreOffice's patches.
Viral licenses like GPL have an edge and will win out if there is a community that actually cares.
[1] https://cgit.freedesktop.org/libreoffice/core/log/?h=aoo%2Ft...