Kudos to you and the original poster; well-stated and thoughtful. Just to add a touch of gilding to the lily...

I've read (can't recall where) discussions of the difference between what we might call exploratory programming and task-driven programming. In one case the goal is to learn something (feature of the language, a new technique, how a published algorithm works, a design pattern, etc.); in the other the goal is to produce a concrete result (typically under time pressure). While the two goals can mix, they usually are pursued separately under different mental states, which don't mix. A person engaged in one will typically be frustrated by interaction with a person engaged in the other (e.g., thinking of the other as "goofing off" or "being a stick-in-the-mud").

I believe that it's important to have a well-balanced mixture of the two. Although my job involves the creation of code, I feel a day has been lost if I don't learn something (and today I'm usually glad for what I learned yesterday).

Your example of multiplication touches on another interesting contrast: concepts of the problem domain vs. concepts of the programming language. Theoretical mathematics and applied mathematics have developed in a complex dance in which each has taken by turns inspiration and results from the other. Similarly, if the idiom you presented were commonly-enough used, one would expect the DRY principle to drive it into a function. If the function were commonly-enough used, the equivalent operator would become more acceptable. If either became common enough, the concept might "leak" back into the subject area.

All of which is just a round-about way of saying that having fun can be a powerful way to learn (if one is not a stick-in-the-mud).

The darker side of all this is the general "dumbing down" of culture, at least in the US. The media present 15-second sound-bite oversimplifications of complex events/stories. Some employers want to hire inexpensive labor and use them as plug-replaceable factory-line units, even for information-intensive jobs. People of learning and adequate vocabulary are mocked as "eggheads" (or less-flattering terms) instead of respected.

My favorite answer to the above is Dijkstra's response to someone who challenged formal programming techniques as being too difficult for use in the education of "the average programmer". He replied, "What about the education of the average brain-surgeon?"

In medicine, we don't restrict physicians to the narrow range of techniques available to the average nurse's assistant (despite the apparent desires of the insurance industry to second-guess every medical decision and to control treatment by tying payment to their approval of treatment/medication). Similarly, we shouldn't restrict all programmers to the techniques of noobs.

How to get that distinction recognized is another problem.