Let me try a partial answer...
1. Is the current build stable enough to run indefinitely with no EPICS-caused outages?
Tough question for a system that only has been around for 40 years. :-)
Most systems in EPICS installations undergo regular electrical maintenance procedures (typically once a year). But there may be a few systems (think telescopes, cryo plants) with long runners.
@all: Does anyone have outstanding long-runner IOCs?
Personally, I have a lot of trust in the core parts of the IOC software. Resource leaks and instabilities usually turn up and get fixed pretty quickly.
It's locally developed drivers and Device Supports that often get a lot less used and tested. Since they run in the same process as the core parts, a bug in a driver can degrade or crash your IOC process.
There are ways to run the IOC processes that would restart them immediately in the unlikely case of a crash, so that clients would just see a disconnect/reconnect flicker.
Also, system architecture can help. E.g., handling the long upstream connection and health monitoring in one IOC and the local controller connection in a separate one wouldn't leave the remote end blind if the controller IOC is in trouble.
The EPICS network protocols (Channel Access, PV Access) are scalable and robustly handling disconnect/reconnect situations. If you have outages in your network, the EPICS layer will not significantly add to it.
5. Are there any plans/projects to implement more stringent information security mechanisms into the system (e.g., something consistent with NIST, IEC, etc. for critical infrastructure)?
There is a current project to add TLS (that would be IEC 62351) to the newer PV Access protocol. Prototype stage. Certificate handling is the hard part that's still ahead. (See the last talk during the last EPICS Collaboration Meeting [1] for more details.)
The older Channel Access protocol can be run through SSH tunnels to achieve a comparable level of security.
Cheers,
~Ralph