A new thing that I learned about the EC curves is that apparently no one is truly using P-384. It's supported in most places, sure, but general maintenance effort appears low. The allmighty OpenSSL doesn't even care enough about it to implement an optimized version for the ubiquitous x86 arch (though an ASM version of P-384 for PPC64 arch was added to OpenSSL recently). Looking in other implementations, we see the same thing: Golang features an optimized version for P-256, like OpenSSL, but not for P-384. Similar stories are found in other crypto libraries (BoringSSL has an ASM version for P-256 in its FIPS module, same for Rust's ring crypto).
Not only makes these non-optimization P-384 fairly slow (its 30x slower compared to P-256 on my machine), but it also makes it feel less maintained and looked at. Some recent research papers on ECDSA implementions barely even look at P-384, but they do always look at P-256.
The Android bug is just another example where some company didn't even test their code with P-384, hence breaking stuff without knowing it.
I wasn't aware of this when the EC hierarchy was first generated in 2020, but since then I've come to dislike the P-384 curve somewhat. It's not the end of the world, so if Let's Encrypt feels that they want to continue going for more bits then go for it, but I personally have begun to think that as long as this curve is so neglected in the industry, it's probably better to stay away from it.