What would a large project that spanned multiple files and >1000 lines show to an employer that a few individual files and a couple hundred lines couldn't capture?
Reason 1: Is it your own code, or something you copied?
(Mostly) anyone can copy a short piece of code from the internet, explore it, and give it as his own during an interview while being able to explain the code itself.
Doing the same with a large codebase would be difficult, since it would be easily recognized and searchable as one of the an open source projects.
Reason 2: Do you have skills to work on a large codebase?
When you give a link to a large codebase under version control, you show that you actually have the skills required to write a large codebase.
When you give a small piece of code, you are showing just that you was able to write a small piece of code. Would you be able to work on a codebase with thousands of lines?
Reason 3: Have you studied/verified your code enough?
For an interviewer, it would be easy to find an issue in a large codebase¹, and to interview you on it. The interviewer may ask if you are aware of one of those bugs, why didn't you solve it, and how do you think to be able to solve it now.
Moreover, during an interview, the interviewer can target any smallest part of the codebase, and ask you to explain it in details, to see how well do you know your own code.
¹ Strangely enough, it is not rare to see small (under 100 lines) pieces of code with one or several bugs where the code is not doing what it is expected to do. This applies as well to candidates who are writing that they have +10 years of professional experience and qualify themselves as highly skillful.
Writing small pieces of code and stitching them together to form a coherent, bigger whole are two different skill sets entirely.
Asking for bigger pieces of code across several files is a way of testing for the latter. I.e. the employer isn’t simply interested in your “coding skills” but in your architectural skills.
In response to the comments on # of errors per KLOC, well, it sounds like we all under-estimate the prevalence of latent bugs in commercial software :) In mission-critical systems (like flight traffic control), 1 error per 100 lines of code is considered average [http://history.nasa.gov/sts1/pages/computer.html]. Per the same link, the software used on the Challenger space shuttle had approximately 1 error per 10K lines; that code cost $1,000 per line to develop.