No, might not be a daft idea at all, it might just be me not understanding your use cases for NR. If it is industrial automation or for a laboratory I can understand but for a normal home user, I doubt it is or will be that common
I'm personally not using NR for such "low level" I/O, I just use "ready made" devices that have a higher level interface. Earlier did much more "low level", built and designed rf rx/tx devices, pic programming, c/c++ etc etc. With age comes convenience, nowadays I try to avoid such things (had however to do some c/c++ AGAIN, just to get my ESP32 doing the stuff I wanted). Also for I/O control, there are already many nodes available, there are nodes for OPC UA, BACnet, Modbus and you can purchase your own Siemens S7 controller and integrate it with NR. I mean if you really are going professional, it's just the cost
You mention Python several times. It might not be good for your use cases for various reasons but I have so many Python scripts running since years in my RPi's. It's working rock solid, very stable. If it consumes resources, I don't really care as long as it fits together with the rest within the limitations. Anyway, they are not time critical so then it's ok having not the best from performance point of view
This discussion is or should, as I read & understand it, also cover a discussion about interfacing and integrations in general. Is an important system architecture aspect. For many years I was the product owner and responsible for developing interfaces between many kind of systems and products to our professional management system used by customers in many countries. I had a team of 30+ developers and project managers, we used C#, C++, Python, Cython. Most of the effort was actually spent on "things" next to the coding; quality processes, system testing on all levels, development and end user documentation etc etc. What was an interesting take-away, or lesson learned, was that the maintenance workload increased dramatically the more interfaces we produced. New versions required due to new updates in the underlying systems and products, new features required...and please note, the interface to our management systems was still unchanged and the same, we used ActiveMQ, another high performance MQ system. After a certain time we spent more time and effort on maintaining existing interfaces than creating new ones
The difference was that we all had salary for doing this. Here with NR, we are expecting deliveries from an unpaid community. Expectations should therefore be tuned accordingly
