Change:
The DTLSCiphertext header is tightly bit-packed, as shown below: <ins> The C bit is set if the connection ID is present. The L bit is set if the length is present. </ins> The low order two bits of the epoch. <del> The low order 14 bits of the record sequence number. </del> <ins> The size of the sequence number.  0 means an 8-bit sequence number, 1 means 16-bit. </ins> <del> Identical to the length field in a TLS 1.3 record. </del> <ins> The low order 8 or 16 bits of the record sequence number.  This value is 16 bits if the S bit is set to 1, and 8 bits if the S bit is 0. </ins> Variable length connection ID.  The connection ID concept is described in I-D.ietf-tls-dtls-connection-id.  An example can be found in connection-id-example. <ins> Identical to the length field in a TLS 1.3 record. </ins> As with previous versions of DTLS, multiple DTLSPlaintext and DTLSCiphertext records can be included in the same underlying transport datagram.

Discussion:
This is a bikeshed colour, but I think a good one. In the 5 bits that we have, we can pack two epoch bits (we only need one in practice, but let's leave that aside for the moment), and a bit each to signal presence of connection ID and length. That leaves one spare bit. I'm suggesting that we spend this on signaling the difference between an 8-bit and 16-bit sequence number. 16 bits is far more comfortable than 14, and 8 is probably enough for many use cases (saving a byte). That is, unless you were saving this for a spin bit and VEC. This doesn't do anything about , but I think that we can save a bit from the epoch. More on that later.
If epoch can be one bit - the you provided is quite convincing - then this proposal could coexist with .
Instead of , make the fixed prefix by picking one of the three reserved bits: This way the implicit Content Type allocation is halved to [48, 63] and we get back 16 codepoints.
I think that we can do better. I've just opened . That uses all the bits in that first octet, which would seem to be a regression, but there are two ways in which we could get another bit back. The first option is to drop the S-bit I propose and have sequence numbers be 16 bits always. I'd be sad that we lost the small optimization, but that isn't the end of the world. Perhaps a better option is to drop the second epoch bit. This seems like a bad idea because you potentially have multiple epochs inbound to a server during a 0-RTT handshake. In that case, you have to distinguish between ClientHello (001 or 0011 would work for that), 0-RTT (epoch 1), Handshake (epoch 2), and the ultimate Application Data (epoch 3). If you only have one bit of epoch, then 1 and 3 are indistinguishable. However, if you look at the way we handle 0-RTT in stacks, it might be OK to allow those late-arriving 0-RTT records to be dropped. For instance, NSS processes 0-RTT and handshake linearly.

We don't read the Finished until we have the EndOfEarlyData, and as soon as we process the EOED, we stop accepting new 0-RTT. Part of the reason for this is that once we report handshake success, we don't provide any other signal to an application about the data it receives. So, for NSS, dropping 0-RTT when 1-RTT is available wouldn't change anything for us. The final option is to not worry about this. The codepoints are there to use. The number of public bits we have is small, and we don't need to signal content type in the clear any more. As I suggested in discussing tlswg/dtls-conn-id, perhaps the right answer is to backport the TLS 1.3 record format to DTLS 1.2 and use only one codepoint.
With regards to 1. Losing the ability to signal 8- v 16-bits sequence would be a bit of a shame, especially in constrained networks (NAME opinions?), but I agree with you it's not the end of the world and I'd be more than happy to immolate it to get one of the reserved bits back. In fact, one bit is sufficient to build a whole if we'd need to -- for spin bit, VEC, etc. I value that much more than a tiny optimisation. WRT 2. Your argument in favour of dropping the second epoch bit is pretty convincing, so personally I'd be OK with one-bit epoch. So, I guess we could have something like: and 16 bits sequence, always?
You haven't made a convincing case for an extension mechanism to my mind. And given the choice between having two sequence number lengths and extensions, I'd take the former every time.
The appalling amount of cycles we have been spending on devising how to do CID signalling in 1.2 is a very good argument in favour of having some kind of extension built in in 1.3. Next time we realise we missed something we won't have to struggle like Houdini. To me this is far more important than a small optimisation of undetermined benefit.
I don't think this is the right answer.

Given that as soon as we can recognize the CID, we can make extensions without changing the header here, I agree with MTabout filling the bits.