Probably not the best way to frame that up, it's an idea that's been tried time and time again, with the same results.
Think VHS and Betamax. Edison vs. Westinghouse. Why everyone needed to get a new TV or rent a cable box a few years back.
We certainly don't need more proprietary hacks of standard protocols, like 'wireless aquabus' (aquabus is just USB in form factor and protocol with non-standard voltages and max current. UPnP would be the network-based analogue, except it sucks and is insecure).
What's working today in the OT (and IT) environments are documented RESTful APIs and connectivity based on IP. Doesn't matter if the device connects over Ethernet, WiFi, LTE, 5,6, or 7G, or super-mega-aquabus v7 turbo edition, as long as it has a reachable IP address.
A controller only needs to know what keys mean what things in the real world, and what the possible range of values it can get/set. That's where vendor documentation (aka "publishing the API") comes in.
Personally, I think Red Sea is in the driver's seat here, it's pretty easy to work with. Some AI stuff has been reverse-engineered to expose APIs and modules created to allow control from any Python script. And of course, we have our own Reef-Pi to take advantage of those standards.
Mark my words, that will be the next evolution in automation. The ones that accept it will grow market share. The ones that stay a closed ecosystem will see their market share or profit margin shrink.
you definitely seem to know actual examples better than I

And I do agree hacks of protocols is horrible. HDMI for example, can be a nightmare since even with a spec and universal acceptance.. it's got quirks and differences between TV sets implementation that can cause a real headache when developing a box to connect to HDMI.
On the other hand, things like DOCSIS or other standards to make broadband/mobile function, to my limited knowledge, is very well defined and followed.
I also completely agree where IT in general is heading is restful APIs, but wouldn't you agree this requires some level of higher complexity of the device/system first? I have a hard time picturing all wavemakers to have a REST Api to communicate with them, or return pumps

Also, just guessing, that implies IP connectivity (wifi/wired), not sure how a REST api over bluetooth would work in practice

These more individual components is where I thought a standard spec (either existing or new one defined) be best. Whether it's a protocol over bluetooth, usb, IP, etc.
Seneye for example, I assume it's propietary, but they atleast released (somewhat) the spec and a example C program. This has let folks replicate and communicate with the SUD directly. Unfortunately they haven't released the ability to change slides this way, but reading all values you can. That feels like a step in the right direction, unfortunately it's a small player with a niche device tho.
I've tried to reverse engineer my GHL doser for example. Something that is physically large enough and contains multiple ways of connecting (Wireless/wired IP, USB). From best I can tell using wireshark I
think instead of implementing any sort of API over IP, it's just transported their original USB protocol over IP... which makes me think practically it's going to be a challenge for them to move to a fully rest API based solution if even in their application they are still using another protocol.
Unfortunately dont' really see any of this happening. Partly due to the built in legacy of the devices. If companies started with a USB/BT propietary protocol, even if they moderinze their end user GUI it can still mean a massive overhaul 'deeper down' to try and offer something more open/standard (either standard spec or a rich restful api). So often it's much easier for them to maintain their original protocols and just focus on end user experience, hiding away the complexity.
.......and this desire for access and manipulation is really a very small part of an already very small market
......and I do agree eventually, companies which have an open/accessible platform will prevail. Whether that's 5 years or 15 years I don't know
