Process Assignment .

This is great for transient or short-lived processes.  But many systems (regardless of how advisable this is) implement long-lived processes where the overarching parent process will be responsible for launching new subprocesses for months (or years) after its initializiation.  The issue here is, there's no way to control or mitigate who is registered as the "initiator" for the parent process, and it's inherited down through subprocesses 100% as-is.

So if this long-running instance is launched by a user who then subsequently leaves the organization - well, suddenly you have severe and not-well-explained errors all over your process instance.  Because subprocesses, rules, etc, will be trying to run under the authority of a deactivated user (and, again, there's no way to change or mitigate this within a running instance).

I know the kneejerk reaction to this is to simply toss one's hands in the air and say, "well then don't build long-lived processes!", but we both know that's not always a feasible answer, for many potential reasons.  Until we are given more granular and/or flexible controls over the "initiated by" property of subprocess calls, i'm afraid in many cases the ultimate answer will be to launch subprocesses under Designer authority.  IMHO, if your security setup is such that you're relying on the initiator-user's security to ensure against improper access, then things have not been set up correctly; this should be a last-resort fallback, not a primary method of access control to a process instance or its internal functionality.