WebUSB and Web Bluetooth are actually very useful in very specific circumstances. I've seen several internal projects use it to communicate with obscure proprietary hardware that would otherwise require my company (mostly a web dev shop) to rewrite or extend the code with a native component only a few people could maintain reliably.
For most people this stuff is unnecessary, which is why there's permission prompts to these APIs, bbut for certain use cases they're very convenient. Google made a tool that allows flashing firmware onto their Pixel devices directly from websites instead of requiring admin permissions to install some kind of one-off binary tool, for example. Then there's the ESPHome flasher which is very convenient.
ActiveX allowed for breaking out of the web sandbox and running native code, these new APIs don't. They allow more direct communication with devices, but only with permissions and even then with limitations.
If I want a website to communicate with a device, I'd prefer it if they'd stick to the web sandbox instead of requiring a native tool. These APIs help prevent an ActiveX world where everything needs an app that runs native code, with all security implications that comes with, and help people stick to the web sandbox.
Perhaps that's why Apple refuses to implement certain APIs, they make billions from the ActiveX world that has come out of the app store.