Like everyone has previously stated, the programming is an extremely complex system of AOI instructions, I am not sure how anyone could navigate the programming to find an issue.
Still not sure why they call it a DCS? It's still a PLC with a graphics package....
If the programming is done in a logical way, finding an issue is usually a breeze compared to a regular PLC program. Part of the reason for this is that their AOI's have been tested far more than a regular PLC program has. The function blocks all follow a documented standardized interface and there is documentation explaining exactly what the block does.
I would organize my code per tag number where each tag number would have an FBD code sheet. In it you place all the blocks related to that tag number and the conditions for it to work (interlocks and so on).
Once all of this is done, you'll realize that there is very little, if any, code left on a chemical process that requires dealing with.
You'd then compile the graphics package, put some lipstick on it and you're ready to roll.
I honestly felt the same way when I was confronted with PCS7, but after a little while realized how much more you can get done compared to the normal PLC environment, that it does make sense to use these DCS packages for chemical processing plants. Obviously, this wouldn't work nicely in a packaging machine, but there is a place for these systems in the market for sure.
Edit:
You can also get a glimpse of PlantPAx on RS Studio 30 if you have it with you. If you look at the ALMD and ALMA instructions, I am willing to bet they are the ones used by PlantPAx so that you can create and manage alarms in a consistent way. If you use these, you configure the entire behaviour of the alarm directly from the PLC and the HMI will follow suit. This is exactly what is done on a DCS package.