Not really helping 2). The encryption is an optional feature, so you can work on reversing and generating your own bitstream as you wish without this.

Being able to fake the signature might help people wanting to backdoor devices in the wild.

Woah, from what I undeddtand, the bitstream is the fpga equivalent of the compiler output? Then selling something as "secure" because nobody can know what code it is running would be security through obscurity no? How would vendors get away with that sort of BS?

To be clear: just talking about the confidentiality requirement here. Authenticity (ie code signing, right?) is obviously something very useful especially in these cases.

This is about bitstream encryption, so there is an expectation of confidentiality. The keys needed to decrypt the bitstream are stored in nonvolatile memory on the FPGA itself. Assuming that it is implemented correctly (evidently not in this case), it is impossible to decrypt the bitstream without analyzing the FPGA die itself, using tools that are usually beyond what a casual attacker might have. It probably won't stop a nation-state from figuring out how to read out your FPGA design, but it will probably slow down your competitors.

Yes, for IP protection I get why that's interesting. But crucially, it's the vendor's interest. For a hospital or such, the interest is actually opposed to this. They should be looking for secure software that is as open as possible to allow for audit and servicing if needed. So selling DRM as something that somehow makes the customer more secure is BS.