We typically encourage use of Mango in a mainly supervisory role to the controller. In my mind, it would primarily matter about how the timing and response needs to be. Should you require a response time that is always necessarily predictable and minuscule, you could encounter complications with things like Java garbage collection and whatnot. Having a webserver would provide an opportunity to spontaneously increase the memory load of the unit, and if it paused control when millisecond timing was important, that would be a problem. I would not let Mango time my engine's firing. But, I wouldn't hesitate to let it toggle my vehicle between driving modes (if I had such modes).
Beyond timing as a concern (because it will respond within seconds almost always), one could question the reliability of the endeavor. Mango is crashable. You can crash it still by doing things like running massive reports or kicking off an infinite loop in a script validation. What's more, Mango has a webserver, so you need to either lock down access or your control system could get hit with a denial of service attack. Bad news. Then there are the issues that the user of Mango could build into their solution (in haste or innocence) because Mango is complex. If Mango is logging data and the disk fills up, you wouldn't want the process control to suffer. Then there are issues [a] developer[s] create[d], because Mango is complex.
I'm not familiar with cascading pumps for demand, so I can't comment on the specific problems you may face there. But I certainly think you can have Mango making determinations in your distributed system and submitting controls, for sure. Most situations are different, so there is just cause for much thought on the redundancies required and the ways Mango could fail in a given system, and how the system can fail. We always encourage publishing the data to a cloud Mango instance if you are doing controls with Mango, and then visualizing your data in the cloud instance. We are a SCADA platform, we do SCADA applications.