>The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code.
I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less abstraction, even if it leads to more verbose code. That's the whole secret of Java. I've been implementing a small part of my current project in Go and it has similar benefits.
That said, when working alone or with one or two others, I feel kind of dumb repeating some things over and over at the same level of abstraction. There are lots of things like this little piece of C++ code that I tried to translate into reasonably efficient Go:
template<typename V, typename R>
R defaulted(const V& val, const R& default_val) {
return val == V() ? default_val : val;
}