This post refutes the claim that researchers found a "backdoor" in ESP32 Bluetooth chips. What the researchers highlight (vendor-specific HCI commands to read & write controller memory) is a common design pattern found in other Bluetooth chips from other vendors as well, such as Broadcom, Cypress, and Texas Instruments. Vendor-specific commands in Bluetooth effectively constitute a "private API", and a company's choice to not publicly document their private API does not constitute a "backdoor".
I tried to offer a gentler backgrounder on this HCI business: https://lemmy.ml/comment/17160273
The opcodes that actually jumped out at me more than the undocumented ones were the ones that erases the flash.
But the conclusion stands. None of this is a ‘backdoor’ unless you can secretly access it from the wireless side and nothing in the presentation points to that. If I had to guess, the opcodes are for QA and tuning on the manufacturing line.