I see this slightly differently. Before, if I wanted to be able to do something like flash firmware onto some device I would have to download some random C++ application and install and run it on my local machine. As well as having access to all of my USB devices, it also had access to everything else on my system's user context. I didn't have a way of running that code and only giving it access to a single USB device and nothing else. Now, I can avoid installing anything at all. I visit the project page and opt-in to some flashing flow that's running in a sandboxed env. When the app requests it, the browser asks me for permission and I get to choose exactly which USB device I want to give it access too. That's picking exactly the minimum "outside" access I want to give it, nothing more. It doesnt get to read/write other USB devices I didnt choose. I doesnt get to read/write to my filesystem. It doesnt get to call system APIs. It doesnt get to set itself to start at startup. It doesnt get to install an auto-updater. For me, this is a better security posture than installing random win32 apps.

Flashing was already solved by UF2, where the device-to-flash temporarily pretends to be a USB storage device. Giving raw USB access to to random websites for that is massively overkill.

I could understand it if you were trying to do realtime configuration of or interaction with some device like a printer or a Stream Deck, but something as trivial as firmware flashing?