I've spent many years leading and managing development teams. By nature, I am a bit OCD in terms of code and very black-and-white. I've learned through experience that picking your battles is one of the hardest skills to learn as a team lead. Yes, standards are important. Yes, readability and maintainability are incredibly important. Yes, we should all strive to write uniform, standards-compliant code. Developers are humans though... not code generation tools. We have personalities, opinions, we get bored, and we want to learn new things.
On code reviews at work I have been seeing code & patterns that I consider "clever" though not necessarily adding to the overall quality or maintainability of the code base.
OK... so they don't add, but do they detract? Are we talking just a matter of personal preference in coding styles, or is the code being written completely unnecessary (eg. using expression trees and reflection just because it is fun to use expression trees and reflection)? If it is the former, let it go. Part of the fun of being a developer is coming up with creative solutions to problems. Maybe (and most of us don't like to admit this), we sometimes feel intimidated by approaches we don't understand, and either don't want to ask or don't have the additional energy to learn the new approach.
Now, when creativity leads to unnecessary code and completely unjustifiable complexity, then by all means be vocal and make your case. Being a team player is important, but so is being (and holding others) accountable. Code reviews are about accountability as much as quality assurance and learning. You are going to step on some toes, but if you feel like you have a strong argument why effort (money) should be spent rewriting working code AND an ego should be bruised in the process AND you want to risk squashing someone's enthusiasm for their craft, then you shouldn't shy away from putting it on the table. If you are the team lead, this is your job. Be aware of the impact, and do it. If you aren't a team lead and don't have the authority, then put it to the team to decide.
The best way to instill accountability in your team is by encouraging others to hold you accountable. If you keep an open mind and don't shut people down when they suggest improvements to your code, you may find they are more receptive to your suggestions.