It may be easier to write that on a full sized Linux system, but come time to deploy it, all that Linux code that isn't being used is a liability for bugs and unexpected behavior to crop up. One approach is to slim down Linux to avoid that (eg removing systemd, esp for systems that don't have enough ram to run it), but another approach would be to just use something less complicated than Linux. It would suck to get to space only to find that something had messed up permissions on the gpio pins again so your satellite didn't deploy and now you've wasted a launch. If there's no permissions system to mess up, that can't go wrong.
As far as bare metal, I presume it means to port a Unix program which has all sorts of assumptions about running on a Unix operating system, to an OS that's not one, with simplified models for a lot of things, and for the system to reliably run that program on boot and not do anything unecessary. Like run cups.
This is completely impossible with standard Linux. Real-time Linux might offer some guarantees, but I am pretty sure that they are rather soft.
Linux is already too big to be easy to understand and audit in order to be certain that you really know which will be the worst case.
With a simple OS like RTEMS, a competent programmer can become an expert in its internals in a month or so, and then it is easy to understand what exactly will happen in any circumstance.
I have used in the past some commercial real-time operating systems, like pSOS and VxWorks, but the free RTEMS has been much better than those, especially because being open-source it allows a much deeper customization than any proprietary solution.
It's all very well asserting something but a bit more chat would be nice.
I'm not sure what "turn a Unix program into a bare metal program." means.