Language constructs are added to make the life of a programmer easier. He'll have to learn these eventually anyway so you shouldn't be worrying about it.
Its easier to maintain a linq query rather than nested for loops.
I'm against Least-Common-Denominator coding. We're professionals, part of what we should be expected to do is learn things that we don't know.
On the other hand, I'm also against glory-coding. Use the simplest constructs that can get the job done - debugging code is twice as hard as writing it, so you'd better only write code half as clever as you're capable of!
I think the general rule of thumb is to make sure your code is readible with lots of comments, especially in places where you are doing anything that is not straight forward.
Avoiding certain constructs like delegates and lambda expressions shouldn't be the way to go, if used correctly and sensibly, language features like those can greatly reduce the complexity of your code and make them more concise and expressive. After all, that's the beauty of LINQ, is it not? ;-)
I think you should focus on getting your part of the job done as best as you can, whether or not the other programmers have all the necessary knowledge to understand your code is out of your control. If that maintenance programmer leaves, and someone else comes in, what then? You shouldn't tailor your code to suit the maintenance programmer, tailor your code to suit the problem you're tasked to solve instead.
I think that even if you are writing on your own project, it's worth sticking as far as possible to common / standard idioms in whichever language you are using.
I've run into this trap myself - written some code that did something "clever", didn't document it sufficiently, and introduced a serious bug when I came back to change the code a few months later.
My rule of thumb - use the "core language" as much as humanly possible, and when you diverge from this then document your approach thoroughly. Avoid exploiting syntactic sugar to make your code shorter unless it is a really standard idiom (e.g. properties in C#). Readability should trump typing speed every time.
If you are expecting maintenance coders to take over your work, all this is doubly true. You cannot expect maintenance coders to be proficient in multiple paradigms in most organisations. Therefore if you e.g. start using logical / functional programming constructs like lambdas in your object-oriented code then it's a bit like writing a chapter in German in an English book. You might wish your readers were multi-lingual enthusiasts, but it's most likely that they are not.
I believe especially lambda-expressions make the code easier to read if anything. Instead of having multiple for-each's with lots of conditionals - a clean lambda can almost be read.
From my experience things that make code hard to read is clever generic Func arguments... These often only take out tw0+ easy to read functions and replace it with a generic hard-to-read one.
So, it is more important in my book to have methods with good names than avoiding certain constructs. But don't worry about them not knowing them - they should learn them anyhow.