Second question first: Most microprocessor development boards either have a standard connector on them to attach a debugger pod on them that connects to another computer to let it load programs and debug the program running on the system, or they include such a debugger pod on the board, and have a USB connecton to allow the remote computer to do the debugging. The RPi, because it was designed to be running a full OS on it, doesn’t provide such a connector.
First Question, the lack of such a connector makes converting a RPi to run a standalone program very difficult.
Lastly, compared to some embedded systems designed for the purpose, the RPi is big, many embedded boards can be 1/4 the size and price of the RPi (or less). The RPi is a power hog, it needs Watts of power. You can build a small power supply to power a small processor off a single battery for a long time, but don’t try that with a RPi. Yes, those processors have no where near the processing power of the RPi, but you often don’t need that power.
FreeRTOS fits ideally to power programs on such processor/boards, and that is where I believe they consider their primary focus.
For support, the RPi is just an Arm processor, so I suspect that there is already a port that handles most of the details. It might need a driver for the interrupt controller and timer. Some bigger issues though is that the RPi has a multi-core processor. FreeRTOS at its heart only supports a single core per version of FreeRTOS loaded (AMP). There are some third party provided multi-core ports of varying quality, but SMP multi-processor systems have very different issues to solve than single core systems.
In one sense, running FreeRTOS on the RPi hardware would be like going out and buying a fancy racing car, and then using it to only drive around the city. You have hardware capable of doing a lot more than you are using it, and missing a few feature that would be useful for that environment.