Start by talking to them about how you think they are really good at solving problems -- and how one of the challenges you hope they can solve is producing work that others on the team can understand and extend. They may need to first hear you acknowledge that they are talented and that you admire their work -- and then that you wish their work was more accessible to the rest of the team. The idea is that most good engineers will want to produce work that others can understand and appreciate. You just need to make it clear that you consider that part of the domain of problems they should be keeping in mind.

If this goes well, you might also want to acknowledge that this may mean taking less sophisticated, less forward-looking approaches. A lot of over-engineering is like over-training a model to historical data, assuming the future will be exactly like the past. Anyone who's worked on software for very long will be acutely aware that needs change over time.

Thanks all for the comments. I've tried all those approaches, but failed so far. I'll keep trying.

Usually, it's a phase. Right after one acquires what could be called "mastery" of a language there's a period where even the most complex (or obtuse) ways to use the language seem simple.

After a while that high subsides and one starts seeing the elegance of simple solutions for most things and complex ones where it's warranted.

I've seen this before on the other end. Someone learns a mostly useless design pattern then begins to architect every solution using it.