Oplog is pinned as it is need for backup, crash recovery, and rollback (see getPinnedOplog()). When enableMajorityReadConcern is false, no oplog is needed for rollback, so oplog is only pinned for backup and crash recovery. For crash recovery, we only require oplog back to the last stable checkpoint, which can advance beyond the majority commit point. This means oplog can be truncated before it is majority committed.

A result is that in a PSA set, it's easy for the secondary to fall off the back of the primary's oplog, particularly if secondary is down for a long period of time. However, an advantage is that the primary's disk doesn't fill up with oplog, so this could also be considered a feature.