When mentoring individuals, teach clean coding and simple/effective thinking or let them do it their way?
As someone who has now taught CS for many years, let me first reassure you that teaching clear, clean coding is entirely worthwhile. I think this is especially true for those who will not go off into software professionally, because editing, and being able to express ideas in a clean, clear manner is a skill that serves people well in any field.  (I've written a bit about my approach to teaching good coding style before on this site.
Now, USACO is something a bit different. These competitive programming situations are designed for coding speed, program speed, and correct output.  You get no points for maintainable code, clear thinking, or reasonable variable names.  These contests can be great learning experience as long as the student understands that they are getting intense (and good!) practice on only one small piece of a larger puzzle.  I would definitely try to contextualize this for the student, though I caution you that you may never win over this particular student. He may have already become somewhat set in his thinking.
Here's something silly you can do to attempt to demonstrate the value of clean code to the student: take some nice, clean code for a USACO-style problem and introduce an obvious edge-case bug that crashes the program (an array out of bounds or somesuch).  Refactor it to give it USACO-style names, like m and pf. Shove everything into main.  Make sure that there are no strings to make obvious what the program is supposed to do.  Reverse loop styles to make them less appropriate (i.e. switch for and while).  Screw up the indentation. Generally make a mess of it.  Have fun!
Print out your spaghetti onto physical paper and ask the kid to find the bug. You can even tell him the type of bug. Tell him he had 10 minutes.  At the end, ask him what the whole thing does.
Then give him the original version, with clean names, good use of functions, comments to explain what the functions do, and generally clean design. Ask him to find the bug again, and ask him what the code does.
Now tell him that he's just been hired to maintain hundreds of thousands of lines of buggy code that someone else made.  If the code all looked like the first example, how long would he give it before he quit that job?