That entry is poorly-worded, so I don't blame you for getting confused by it.
The author(s) appear to be trying to make the point that even when dirty reads are allowed, it is impossible to encounter changes made by a later update before seeing changes made by an earlier update.
In other words, a 'dirty read' will always include all changes (committed or not) up that point in time.
It seems to be a way to stress a perceived difference compared with non-repeatable reads, as the preceding sentence mentions:
Dirty reads work similarly to non-repeatable reads; however, the second transaction would not need to be committed for the first query to return a different result.
No such distinction appears in the original definitions as I understand them, so it would be better if the part you refer to were removed.
Note that an implementation of read uncommitted isolation is not required to experience dirty reads, just that it may. Several popular products provide a read uncommitted isolation level that delivers a much higher degree of isolation and protection from so-called read phenomena. This is explicitly allowed by the SQL Standard.