The above is part of the Asterix spec.
Some interesting data layouts are on pages:
Page 28 - shows integer fields that span bytes. These are big-endian integers, however the bits are numbered in the prose LSBF. But DFDL doesn't use bit positions, it uses lengths. So that prose isn't needed.
Page 30 - simple example of two single bit fields, followed by a 14-bit big-endian integer
Page 35 - simple example of a single bit followed by a big-endian 15-bit integer
Page 41 - String of 8 characters represented as 6-bit code points. (motivates the proposal for dfdl:character(...) function)
In every case I see, it's very easy to model this data using bitOrder mostSignificantBitFirst and byteOrder bigEndian, and simply specifying the length (in bits) of the elements.
It is just funny to look at the way they number the bits, and talk about the bit positions. Their numbering scheme uses bit 1 as the least-significant bit, but the order they present things starts first with the most significant bit.
So in a 16 bit word, they'll start by describing "bit 16" first, which is the most significant bit first. So their bit numbers are assigned LSBF, but the "first" bit is the most-significant bit, first byte is the most significant byte (bigEndian).
Now bit position numbers really don't play a role in a DFDL schema, so I'd say Asterix is really just bigEndian and mostSignificantBitFirst. There's nothing compelling here about the need for the additional combination of bigEndian with leastSignificantBitFirst bit order.
So I guess I withdraw the suggestion that this combination is really needed by this Asterix format.