There are some cases (make and the Spring Framework) where the user specifies the dependencies between things and the framework does a topological sort to figure out what order to do them in.

Even though this could be a basis for a whole paradigm of programming, professional programmers usually don't find it hard to figure out how to order things so there is little motivation to address this problem systematically. However, I think it is on the list of problems that non-professional programmers (say the subject matter expert who wants to learn Python to put their skills on wheels) get hung up. Instead it's seen as a special case that makes high-complexity systems scalable (... Spring lets you describe the parts of a system and how they are related without writing structurally unstable initialization code.)

I think most "business logic" is fairly linear most of the time, and that even if it's highly branched, usually you don't have a large number of concurrently executing units of logic. You do have things like iterating/mapping over arrays, but that's precisely what I think is generally not "high impact" to parallelize. And when it is high impact, we do in fact have a rich space of tools available in the programming and software world, depending on the nature of the task at hand.

I know nothing why this particular Prolog parallelization project failed, but the above is generally my intuition about parallelism in computer programming, so I imagine it's at least somewhat relevant in this case.