Bluetooth is a wireless technology, and including it necessitates an onboard power source, a battery. This changes the security model a lot, an attacker now only needs proximity to the device, not physical access.
The security model already assumes that the entity requesting authorization is untrusted, so the security model is basically unchanged. An attacker who can forge BT packets to submit bad data for approval is not really different from an attacker who compromises the laptop/phone/etc to submit bad data for approval.
You're assuming that the Bluetooth implementation does not introduce vulnerabilities that thwart this assumption; GP & GGGP are suggesting that you shouldn't have to make this assumption in a hardware wallet (or hardware that requires this very high level of assurance), by not including it at all. The same goes for, say, an attacker who's able to swap your wireless charger for a malicious one, and potentially execute a power usage-based side channel if you access the device while it's charging, or who's able to extract some useful information from the RF noise produced by the monitor.
The counterargument to this, in my mind, would be that you plan to use these features of the wallet regularly, and that they provide sufficient benefit to justify the risk (which you may argue is quite modest), and perhaps that you've implemented additional mitigations against them (like never using it while it's charging). Your argument about a monitor adding additional assurance in a sibling thread was quite good I thought, and a tact I didn't anticipate in this list originally.
So this isn’t really different from having a USB cable: in either case, some untrusted messages arrive at the secure element over some wires, and get processed there. The only difference is that the wires come from another chip on-device rather than from an external cable.
[0]: https://www.ledger.com/ledger-nano-x-bluetooth-security-mode...
I'd be surprised if that was the case. Nano X and S+ use the secure element for key operations as well as for user I/O (display and button control), which is significantly better than delegating that to a "main processor".
Given the complexity of driving a touchscreen and e-ink display, I think they might have had to return to that weaker "multi-chip" model (used in the original Nano and earlier and by many other hardware wallets), where the non-secure chip drives both the UI and I/O, rather than only latter.