The sheer quantity of edge cases, special cases and normal use cases when dealing with these "mundane" entities is a quality all its own. These use cases we aut

The sheer quantity of edge cases, special cases and normal use cases when dealing with these "mundane" entities is a quality all its own. These use cases we automate or help automate are not by themselves all that complex normally. This is where they differ from quantum mechanics, synthetic chemistry, etc., in that use cases in those fields are usually not as accessible to the layperson. Yes, go deeply enough into those "mundane" entities and you will eventually hit a abstraction strata high enough where it makes sense to apply a Lisp/functional language/<<insert favorite abstraction tool here>>. But in the meantime, many times even the domain experts themselves don't realize there even exist higher abstraction levels of their domain. Incrementally getting there with the lower-abstraction-capable languages often better fit their organizations' staffing budgets today. Lisp programmers by and large I've found are scary-category smart. Consistently staffing that kind of smart takes bigger payroll budgets than most organizations are willing to stump up. Today, the tooling around getting "good enough" results in most fields for most projects tends to even out whatever programmer productivity efficiencies Lisps brought to the table, enough to the point where most managers don't want to tackle the higher complexity of managing a Lisp team.