to ensure that physically corrupt data is not read
I imagine that physically corrupt data means that whatever physical container holds the data - typically blocks or pages - always deliver a sound and well formatted structure, no matter what failures happen.
The lowest storage unit of a relational database is traditionally called a page or a block. A page is usually formed by multiple disk I/O units (disk blocks or sectors). The I/O subsystem guarantees that a sector is always written as an atomic I/O unit: it either succeeds or fails.
However, if (as is pretty much always the case) a page is formed by multiple sectors, then changes to that page need to be written in multiple sectors, as a consistent unit: either all sectors are written - or none is written. The OS I/O subsystem does not automatically guarantee that:
the lower level of the RDBMS (the I/O manager generally) must guarantee that instead.
This is what that sentence means: even when I use the read uncommitted isolation level, there is still a minimal consistency level that guarantees that the physical storage units of the database (the pages) are always consistent at the physical level.