There is a lot of space between bare metal and stdio. You said that you are not writing the kernel of the OS, but whether you use it under the OS.
When performing directly on hardware without an OS, you still want to encapsulate all your I / O operations in the module, even if you do not formally define the device driver interface and keep track of the framework for all your I / O modules. This is extremely architecture dependent and you are responsible for knowing all the details of the interaction with each I / O device you have ever used. For some devices, this can quickly become a huge development attempt. This is not a problem for embedded systems, but working on commercial equipment this way is not easy and is not recommended.
Running on the OS, you probably do not (and should not) get access to the actual hardware registers and interrupts. If you are developing a custom I / O device, it is best to use it in accordance with existing standards so that you have as little user-level low software as possible. That's why you see a lot of customizable user interface gadgets that connect via USB and identify themselves as HIDs (user interface devices). As HIDs, existing USB drivers take care of the physical layer, and the HID driver supplied with the OS takes care of the logical interface, providing the application with a very simple high-level access API.
One of the key roles of the operating system is to provide a consistent I / O API for all devices. As a rule, this takes the form of the functions open() , close() , read() , write() and ioctl() (names change, but in any case at least the first four will always exist). However, the OS level is pretty crude. Typically, an OS call is forwarded without much processing to the device driver, which then sends the data to the device. Typically, low-level OS calls block the caller until they end, and often they have buffer sizes that make sense. For example, raw access to a disk device is usually required for an integer number of disk blocks at a time.
And don't forget about things like file systems and network protocols ... they are all made much more reliable and compatible with encapsulation in the operating system.
Even if it's permissible to call read() and write() for single characters, this is usually not the best performance. Operating system calls are relatively expensive, and if you can read several characters in one call, your performance can go up.
This is the source of the stdio library for C and various other buffering libraries in other environments. The stdio library provides a buffering level that isolates C code from the block size of the underlying hardware. Even in a fully home operating system, where you have full control over all devices, something like C stdio will still be valuable.
Writing your own stdio replacement is a very valuable exercise, even if you don't use it in production code, and I would recommend to anyone who wants to know what really happens between printf() and scanf() and the terminal or files.
One valuable resource is the C Standard Library book, written by P.J. Plauger. In it, the author presents an implementation of the complete C runtime library specified in the ANSI standard. His discussion of the specific implementation options that he made is valuable and relevant to the context of this issue, and the discussion of why some of the standard library functions were indicated is also interesting.