I'm learning the internals of Postgres replication and its CDC implementation in Debezium, and I'm using Debezium as one of the sources.
 
The WalPositionLocator JavaDoc states:

The LSNs are not guaranteed to be ordered in the WAL.

In my current understanding, this is not true. The changes are ordered by their LSN in the WAL. They only appear unordered from the logical replication client's standpoint because this is how logical decoding works.

The changes from parallel transaction may be interleaved in the WAL, but the WAL sender serializes them in a way that transactions are serialized and ordered in by their commit LSN. The changes within each transaction are ordered by LSN.

I couldn't find the exact wording as above in the official documentation, but some references may be found in 3rd party articles. For example here:

Logical decoding needs to present changes in the exact order transactions were committed. However, changes from different concurrent transactions are interleaved within the WAL. To solve this, PostgreSQL uses an in-memory area called the Reorder Buffer. Its job is to collect decoded changes belonging to transactions that are still in progress. Only when a transaction commits are its changes released from the buffer in the correct sequence.