OP's point is that the best way to write maintainable code is using bog standard, boring code and leaving clever solutions to the level of the problem domain.
Bog-standard meaning not testable and not contract-based?
Clever solutions and abstractions (hey, immutability is clever right?) can really help out reasoning.
And sometimes you really need clever things due to problem domain, so you really end up with totally not boring code.
For example, you wouldn't cook up your own matrix manipulation everywhere, so you use a clever solution instead. Writing operations directly opposed to composing and optimizing them.
Or in high performance world, using a much more complex but lock-free algorithm instead of the "bog-standard" locked one, sometimes the benefit is huge.
The real important part is to exactly document the clever parts and enforce contracts on them, so you do not end up with potpourri everywhere.
But that is a trivial statement considering that a Turing-complete subset of most (all?) languages is relatively simple.
The point addressed by the article is maintainable code, which is something else.