Yes, delivering device control software in a browser with webusb from a cloud platform will usher in a whole new chapter of keeping people from truly owning the scientific research equipment they have procured!
It's quite worrying seeing the Chrome team have such blatant disrespect for basic security. Rather than using an allowlist for known-good devices or using some kind of handshake to validate the device is okay with a certain website talking to it, they use a blocklist to prevent a website from messing with things like keyboards/mice/u2f keys. It's a massive footgun waiting to go off.
Firefox refuses to implement those APIs due to security concerns, and until they do a serious design overhaul it'd probably be better if Chrome hid it behind a default-off feature switch too.
On the other hand, I've always hated how even something I've written for myself can be hobbled at the alter of security out of religious zeal. At one point you really couldn't access local files, although the orthodoxy has now shifted. I just wish it were easy to just point to a directory and say that's all you're getting, but do whatever you want in there.
Of course, there's nothing fundamentally new there, I'm sure Java applets could have done it on a serial port if somebody tried, but it was impressive given how gimped most os-level access is in a browser.
So I would imagine you could write just enough webusb code to get new instruments to work that you wouldn't need local apps as a manufacturer.