Firefox OS needed those sorts of things for its “apps” since it had no lower-level “native”, and I think that they were only exposing features like that to trusted code (meaning apps you deliberately installed) rather than general web content, until they could be sure it was reasonable.

I think they also designed the OS with a better peripheral security model than Windows/Linux/macOS, nullifying or mitigating one of the two critical problems of WebUSB (that the computer trusts peripherals too much, so that one that’s hijacked can more easily become a remote code execution vulnerability).

(I write all this as one who kept a fairly close eye on Firefox OS, but has never run it.)

WebUSB is so scary for security because neither USB devices nor desktop operating systems have been written with such a use case in mind. There are two key problems in WebUSB: ⓐ USB devices weren’t designed with public exposure in mind, so that they’re commonly insecure and brickable or hijackable if you get access to them; and ⓑ operating systems weren’t designed with malicious USB devices in mind. Combine these, and you’ve got potential total sandbox escape and remote code execution, guarded only by a flimsy permissions popup that doesn’t explain what can happen—can’t explain what can happen. The threat here is probably the most severe (using the definition in the severity/probability model of risk assessment) ever contemplated for the web.

Yes, there are legitimate uses of such an API. Yes, this makes life much easier and even safer for such uses. But if the concept doesn’t also give you the heeby-jeebies, you haven’t thought the implications through enough, haven’t seen how bad programmers are at their jobs, and haven’t observed how hopelessly ineffective permissions popups are at protecting users. I watched the video in your article and was horrified that it’s not even trying to protect you or indicate that this is anything other than routine: you just get a “‹origin› wants to connect” popup with a list of routinely-cryptic device names (“ILCE-6600” rather than “Sony α6600”) that you can choose from. Yet this is a thing that, with the wrong USB device and a malicious attacker that knows about a vulnerability in it, could literally set fire to your computer, steal all your passwords, or silently install malware on the USB device or computer.

For myself, I might prefer to have WebUSB, because I trust my judgement in what I execute and because it’s more likely to support my platform. But for the population at large, on the balance of things, no, I agree with Mozilla’s position that it’s harmful, and would regretfully condemn people to continue downloading and executing untrusted code from the manufacturer, because that’s more likely to be done deliberately and only for first-party code.

WebUSB is problematic because there’s probably no safe subset of its functionality: it seems to be fundamentally dangerous. People have tried proposing a few subsets, from memory (I’ve occasionally paid a little attention to it), but so far they’ve all been rejected as either not safe enough or too crippling; and so Chromium has declined to be crippled and implemented the wildly unsafe with only mild mitigations to limit the class of devices exposed, and Gecko and WebKit have declined to play it dangerously. It’s similar to the question of exposing raw TCP, which was contemplated, but ended up being deemed too dangerous, and so it was wrapped up in HTTP as WebSockets: something not quite as useful, but safe. It’s possible someone could come up with something like that for WebUSB, something that constrains it to something safe. Such a constraint could easily require major API changes. That WebUSB currently matches the fundamental USB concepts closely is no saving grace in the stability of the protocol.