This is a rough analogy based on the SwissArmyKnife. I have proposed in some heated topics that too many paradigms and/or language idioms used in a given shop confuses typical developers, as found in the field. (This is based on my personal experience and observations. Some adamantly disagree with my observations, indicating their own observations are very different.)

When designing a SwissArmyKnife ("knife" for short hereafter) for the field soldiers, one has to weigh tradeoffs. A knife with too many blades will weigh down a soldier. In our context, I'll say that if it's too big it weighs down the developer's brain, giving the developer too many choices which may '''slow down their thinking, and/or require training they don't have'''. It may also result in the selection of the wrong blade because the more blades you have, the more choices you have to consider, increasing the chances of selecting a non-optimum existing blade.

Thus, the optimum is a set of blades/widgets that cover a good gamut of tasks without having too many blades. For example, we don't want 6 cutting blades and only 2 screw-drivers, but rather a roughly even mix of 4 cutting blades and 4 screw-drivers. Nor do we want 8 cutters and 8 screwers if they are relatively similar to each neighbor and end up just bloating up the knife. 

This is assuming screwing and cutting tasks are roughly evenly encountered in the field, which they may or may not be. Considering the mix and proportion of field tasks is also something the knife designer has to consider. In programming, SystemsSoftware needs are often different than custom business application needs, for example. SystemsSoftware (or "core" libraries) typically has to be more fastidiously designed: design and programming errors are more costly the deeper they are in the "guts".

If we really need a large quantity of blades, then perhaps a different approach should be taken. Perhaps the knife can be a Lego- or Tinkertoy-like kit where one can fabricate their blade/gismo in the field. You may have a stem maker with a sliding tube(s) to make a long and/or short and/or angled handle, and the head attachments may be mostly interchangeable and combine-able with each other to make complex heads. Such a building-block approach is probably the most flexible approach to a SwissArmyKnife being one can potentially get pretty close to the ideal tool for a given task. Having a long, short, or angled handle is independent of head choice, for example, unlike prefabricated blades/widgets found in the traditional knife.

HOWEVER, such a tool would probably require more training and practice to use effectively and quickly in the field: its more abstract. One could say it's '''comparable to Lisp''' in that a few key language idioms can be made into just about any programming language idiom one wants: OOP, FP, while loops, for loops, case/switch lists, etc. all without being hard-wired into the language. But this flexibility confuses typical developers. A custom blade/widget made by another or former team-mate may not be as familiar or as well understood (less "comfortable in the hand") than the pre-selected blades/widgets of the traditional SwissArmyKnife.

Typical developers need some degree of '''"paint by numbers"''' in their tools to be productive, for good or bad. They are not master painters/artist, but rather template gluers. I'm just the messenger.

Many (correctly) view programming as a stepping stone to manager or other field that has more staying power, career-wise. Programming is tedious and hard on the fingers, eyes, and gut and has relatively low status such that its often viewed is merely a stepping-stone job. Thus, becoming a master painter is not given a high priority. Further, being a master painter is often not rewarded because it requires colleagues to know your techniques to modify your paintings, which they often don't. A localized QwertySyndrome forms where excess abstraction is not welcome because enough would have to first adapt (both current and future staff) to make it viable for team-scale programming, and that threshold hump is unlikely to be reached.

--top

''What is a "typical developer"?  The typical developers I know sound very different from the typical developers you know.  The typical developers I know are usually educated in ComputerScience, are highly capable in multiple languages, can program the full stack, are effective in multiple programming paradigms, and don't bat an eyelash over using Lisp or anything else.  To them, languages are just languages.  Notably, they don't regard programming as a stepping-stone, they regard it as a beautiful craft -- equal parts mathematics, science, technology, and art.''

''"Typical developer" sounds a lot like "typical house" or "typical meal" or "typical car".  It's so dependent on context that I don't think it means anything.''

IndividualExperienceShapesPerceptions covers similar territory. We can LetTheReaderDecide which staff picture best matches their own shop and apply the relevant discussion or recommendations. For example, if a given shop is staffed with experienced programming geniuses and is likely to stay that way for a while, then obviously much of the above doesn't apply. That way we don't have to keep bickering over how developers "really are" in a global sense.