If you look at
git blame of BOLT 03 you can track the sentence regarding the locktime down to this commit: https://github.com/lightningnetwork/lightning-rfc/commit/f1eaa2544665c9b85a2fd95be9c83dad45888982
luckily the author gave a good explanation in the commitment message in git of why the
0x20 was introduced for the upper 8 bits in the locktime field (I have nothing to add to this):
Use 0x20 as high byte for locktime in commitment transaction
The most significant byte of the locktime in a commitment transaction
must be set to 0x20. This is to make sure that the locktime value
is always higher than 500,000,000, making it interpreted as a Unix
epoch timestamp, and not a block height. It also makes sure that the
locktime is below the current time, allowing the commitment transaction
to be included in a block.
Since the sequence field in the input of the commitment transaction is
used for the other half of the obscured commitment transaction number,
it will never assume the maxInt value (0xFFFFFFFF) which would disable
Similarly for the first 8 bits of the sequence number we find this commit: https://github.com/lightningnetwork/lightning-rfc/commit/125b9a36572d05eb79b1c9527a70acadadc7cfc1 From the commit message I can quote again:
BOLT 3: Fix commitment transaction input sequence number.
From BIP 68:
If bit (1 << 31) of the sequence number is set, then no consensus
meaning is applied to the sequence number and can be included in any
block under all currently possible circumstances.
Which is what we want.