The TransactionOptions struct includes a member for readPreference with the following justification:

Because primary is the only read preference allowed with transactions in MongoDB 4.0, this specification could have omitted TransactionOptions.readPreference, or at least defaulted the read preference to primary instead of inheriting the client's read preference. However, this would have required a breaking change circa MongoDB 4.2 when we introduce secondary reads in transactions: TransactionOptions will inherit the client's read preference in 4.2, so for the sake of future-compatibility, TransactionOptions inherits the client's read preference now.

In MongoDB 4.0, the error "read preference in a transaction must be primary" is thrown whenever the application attempts a read operation in a transaction with a non-primary read preference. We considered throwing this error from startTransaction instead, to make the error more deterministic and reduce the performance burden of re-checking the TransactionOptions on each operation. However, this behavior will have to change when we introduce secondary reads in transactions. There will then be new error scenarios, such as a transaction with secondary reads followed by a write. It won't be possible in the future for startTransaction to check that the read preference is correct for all operations the application will perform in the transaction. Therefore, we specify now that the readPreference must be checked per-operation. (However, we have not completely planned how read preference validation will behave in MongoDB 4.2.)

https://github.com/mongodb/specifications/blob/e9b4c96f3ff9b639c61feb7ed149ed14b59aabb6/source/transactions/transactions.rst#why-is-readpreference-part-of-transactionoptions

However there is no such feature as "read-only transactions on secondaries" nor based on the state of PM-1094 does it appear there are any plans to add such a feature. Instead, the equivalent behavior was delivered through snapshot reads on secondaries in MongoDB 5.0 (PM-1504) and has a syntax with sessions independent of the syntax with transactions (DRIVERS-815). Given the only read preference which matters for transactions is therefore {mode: "primary"} it seems best to remove the illusion of choice from application developers.