The traditional name for I/O that locks up the task is blocking I/O.

Most OS allows a read to be blocking or nonblocking. If nonblocking then you instantly get the number of characters available - which may be zero. If blocking, then the call will wait until the requested number of characters are available, or until the input stream is closed.

In some situations, blocking I/O is combined with event handlers, so the program gets an event when there is enough data or buffer space so that a read() or write() call will be safe to do without locking up.

In some situations, blocking I/O is combined with special poll/wait functions to either query the availability or to wait on multiple, concurrent, I/O operations.

But no, I do not think RTOS got introduced because of blocking I/O. I think they got introduced to allow long calculations to be run without the introduction of large numbers of tests if other work has to be quickly done before continuing with the original work.

With or without an OS, it's trivial to greate I/O solutions that doesn't block.

But without a preemptive OS, you always have to introduce manuall polling.
And without ta task-switching OS, you often have to introduce very fancy state machines to be able to figure out where to continue.

People really shouldn't select an RTOS because they want to wait on I/O. They should do it because of the complexity of the code. Some algorithms are very hard or inefficient to use in a state machine. An example may be a large sort operation. Say a recursive quick-sort. Oops - quickly recurse out just to do somethingelse, and then restart the sort with - hopefully - a slightly more sorted array.