[jandrewrogers]

You are misunderstanding the problem. Any systems problem can be decomposed into a discrete problems with sufficient fidelity to satisfy a quality requirement. The problem is that the number of discrete components in the model required to provide sufficient fidelity to minimize complexity can frequently number in the millions. No human can reason about that. All you've done is move the abstractions around. Many physical engineering systems have this property; it is in fact a major use of high-end compute resources.

Traditional engineering disciplines that routinely have this problem of non-decomposability actually treat it as a systems problem (or a supercomputing problem), they don't shy away from it simply because the cognitive complexity is difficult. They convert the entire system into a set of simultaneous equations that needs to be solved for. In software, we would call this designing a monolith, but the reason it is done in traditional engineering disciplines is that you can't wish away the fundamental nature of the problem. In software, because it is not a physical engineering discipline, you can pretend that this issue doesn't exist, for a while at least.

Systems complexity is intrinsic, there is no trivial reduction. If there was engineers of all types would serve little purpose. Not coincidentally, the engineers that command the highest salaries are those that have the cognitive capacity to reason about the most complex systems dynamics, the dynamics that can't be decomposed into independent sub-problems before understanding the behavior of the entire system.