FPGAs aren't inherently secure. I'd assume that a nation-state-level actor would have the ability to extract the bitstream from an operating FPGA which would invalidate both of your statements if additional protections and security considerations are not met in the hardware design. But you are correct that an FPGA readout is a far more difficult attack than, say, bypassing the read protection on a microcontroller's flash. At the same time, it might be easier to attack an FPGA than a modern CPU's secure area/secure enclave.
That is all to say the security is not coming the FPGA but from a systems design process that prioritizes security. There are a number of solutions to the problem which may or may not involve FPGAs but when you scramble it all up along with the preverse incentives driving the pricing/costing of these contracts, it's pretty clear that good+expensive solutions are chosen more often than good+inexpensive solutions.
What are you doing with a Xilinx bitstream even if you have it besides producing more of the device without authorization?
How exactly are you analyzing it for any meaningful information?
It's absolutely not "easier" to attack an FPGA in this manner because the information yielded isn't something a smart fellow can just pop into IDA and glean every secret from: it's a highly optimized gate configuration with massive amounts of redundant register, LUT, etc. insertion. All structures resembling "code" are gone.
You'll never see RTL from this information and there's nothing like assembler for it.
All of this is assuming that the nation state actor can keep the device powered while doing this extraction, because once that voltage drops even a couple hundred mV below the allowed value, that bitstream is gone. Tamper switch, timer, batteries dead, a 30 cent microcontroller analyzing environmental conditions, velocity, etc. and cutting the power: it's gone forever.
I'm not suggesting that FPGAs are easy to exploit; I'm saying that the premise that they are fundamentally secure and/or the only way to implement this requirement is wrong. Having a hypothetical discussion about how an FPGA might be attacked is not the point. Your entire premise is a handwaving argument reliant on security by obscurity, and furthermore its not even correct. Once you can reconstruct the netlist its game over.
That is all to say the security is not coming the FPGA but from a systems design process that prioritizes security. There are a number of solutions to the problem which may or may not involve FPGAs but when you scramble it all up along with the preverse incentives driving the pricing/costing of these contracts, it's pretty clear that good+expensive solutions are chosen more often than good+inexpensive solutions.