Just prepare a little demo for the manager, involving a simple test suite. Show him that you have two versions of a script that both accomplish the same goal. One uses readdir, and the other uses his recommendation. Point out how many lines of code are in each version, and how long it took to write each one. To really rub it in, try to explain what all the extra lines in the non-readdir version are doing. (You might have to say that you decided to try out the readdir version on your own, during your lunch break or whatever.)

Next, walk him through the demo: use tools that he's comfortable with to create a new directory and populate it with files (show the inventory with Windows Explorer, etc). Demonstrate that both scripts produce the same correct output. (You could try including a timing benchmark, but this is probably not necessary.)

Then add some new file(s) to the directory, in some way that you already know will cause the "@list = `dir`;" approach to break (you could make it seem like a spontaneous idea to try something "new"), and run the two versions again.

You could explain to him that the "home-grown" approach can be fixed, if you spend more time studying the output of "dir" in all sorts of conditions and make the script a lot more complicated. But once he sees that the version with readdir works correctly, handles the hard case without needing to be fixed, and is shorter / easier / cleaner, he should be able to come to a proper understanding.

(update: If you actually carry through with this idea, it will serve to bolster a couple of very healthy attitudes: (1) test suites are useful, and (2) assumptions about the "right" way to code should not be enforced until they are tested.)