> For example, manual memory management is a detail that should almost always be someplace else because it isn't relevant to solving the problem at hand. So we did this with garbage collectors. However, sometimes we need this detail present (high performance computing and/or constrained hardware ie video games etc).

That's a great example.

IMO looping is another case: I think it is clearer to use constructs like map/filter/group/sum/reduce instead of for/while/break/continue/etc. You only really need the procedural ones in hot-paths and such.

Concurrency too: in Javascript you had to nest callbacks and promises, and they were also "too noisy". Async/await helps you keep your code more readable. I think Fibers in Ruby (and other languages) were a good idea too.

-

> If you push too many things together that do not belong together, then you end up with code that is hard to comprehend.

That sums it up nicely.

Cross-cutting concerns should be abstracted (but not hidden), as they don't belong together.