It can be deduced from previous information. The firmware interacts only with DisplayPort hardware interface and only when the rest of the device is not initialized. So, it probably does not have access to sufficient information which would allow it to identify you and to discriminate against you. Because it is distributed by NXP without downloader’s identification, a supply chain attack would also not be targeted against you. Because there is no automatic upgrade for it on a Librem 5, you would have to upgrade it manually to be affected by any changes. Because of all that, I do not really see how can it be “mean” to you specifically. If it is or becomes indiscriminately “mean”, then it is just faulty. The firmware might, in theory, have some hardware incompatibilities, but the hardware component of the interface could have them too, so the firmware component does not increase typical associated risks.
That is my impression and I trust Sebastian on that because he saw the code that handles the blob and that code is openly available. If you ask another expert (or “AI” tool), it may make a difference whether they actually saw the code and understand the context of Librem 5. It is quite difficult to make the correct question.
What I am actually concerned here about are simply the bootloader packaging formalities. Das U-Boot bootloader is bundled togeather with firmware blobs into a container before writing it to the device. So, it is difficult to package only the uboot bootloader separately for any practical purposes, such as inclusion as a package into PureOS, or in another FSDG-compliant distribution.
Of course, it would be nice to have the source code for the blob along with documentation for the interface to use every opportunity to improve it.