And you are one-hundred percent correct. Working code works well with resumes, but it's not entirely practical to send a CD-ROM with every resume you send out there, especially when IT departments are already cautious about software they don't directly support as a means of protocol security.
On top of this, you have to consider that hiring managers and recruiters are just the first barrier to defense when it comes to the process of making hiring decisions. Often, they have to place individuals in departments that aren't development, thus, expecting them to look at any code you've produced or software you've written is almost moot. They don't know what the code means, if it's good or bad code and whether or not it's a fair indicator of how your contributions and work ethic can impact the department needing a vacancy filled. At the same time, they have no idea if the software you've provided a download link to is software you wrote over a weekend by copy and pasting tutorial code, without actually learning how to employ critical thinking skills as a developer.
In my work process, when screening clients, a resume entails everything from candidate discovery to candidate placement, it's entirely in the candidates ability to sell to me that they are the candidate for the job vacancy. The physical resume is just the bridge I use to connect that candidate to the hiring manager.
Sifting through resumes is admittedly tiring, but the moment I come across one that has actual accomplishments and enables me with a feeling that this person did more than clock in, crunch away at an IDE, and clocked out, that's when I set that resume to the side and make a mental note that "John Doe deserves a phone call".