I joined a .NET shop two and a half years ago. At the time they were targeting the 2.0 runtime, so one of the first things I did was to include LinqBridge for all the Where, Select, etc IEnumerable extension methods. I'm used to functional programming so that kind of stuff is what I use all the time. Not everyone was familiar with it and got clearly confused, but they picked up quickly, saw the utility, and today everyone is onboard.
So, I think there are two sides to it. Of course overengineering without considering understandability and maintainability should be avoided. But you shouldn't shun or even forbid language features because you don't understand them. I know of places where async/await are banned because the programmers cannot be bothered to learn how to use it. That's not what I think the programming profession should be about. C# regularly gets new language features, and I make sure to pick them up and use the ones I find useful. If someone thinks we shouldn't use some feature, I'm happy to have that discussion, and I will abide to what my team agrees to, but the reason better not be "because I don't understand this feature"!
It's like Perl golf take to an extreme.
(admittedly, some of my co-workers and I have been known to golf our interview questions into ridiculous one-liners, but we do it for amusement value, not because we'd ever write production code that way)
So, for example, the mundane way to square a number in Python would be:
The "clever" way would be: The first one was clear, readable, easy to understand and maintain. The second one is tricky to read, requires some thought to work out what it's doing, and is written to show off knowledge of a slightly-obscure algorithm and the way to implement it in Python.