But what's the point of leaving those bits indeterminate, even in a byte
array? What can one do to them?

One can and should ignore them basically. There are existing ways to type pun long double to __int128. For example, bit-cast to a byte array, clear the upper 6 bytes by hand, and then bit-cast a second time to __int128. It's ugly, but it works.

It would be a bug to read those upper 6 bytes, and making them indeterminate allows UBSan to catch the bug.

As in my reply as feedback: the compiler can avoid emitting the bit-clearing
code if it can tell you did not observe the cleared bits. For example:

uint64_t mantissa_of(long double ldbl)
{
return std::bit_cast<unsigned __int128>(ldbl);
}

This returns the 64 bits of the mantissa of an 80-bit extended precision long
double, which never contain any padding, and therefore the compiler does not
need to clear the unobserved padding bits. And it can be written now, relying
on the compilers emitting suitable code even in spite of it being UB (as per
your intro, but see my feedback email).

But it only works if we fix std::bit_cast<unsigned __int128>.

I suspect that this involves more work than you think. First and foremost, this prevents UBSan from diagnosing what is essentially a read of uninitialized memory. I also don't want to encourage people to write code where some of the bits in their values are unspecified. That seems like playing with fire. For example, all it takes is one typo in a bit mask you use to discard those upper unspecified bits, and you're branching on an unspecified value.

I also don't see how this would work during constant evaluation. We don't usually want unspecified behavior at compile time, and defining when a bitwise AND "un-unspecifies" a value (and other such operations) seems like a lot of core language work which is not warranted here at all.