This is mostly an add to the already volumnous commentary.. But basically, lines of code (or perhaps totalCharacterCount/60) indicates the size of the monster. As a few people have said, that gives a clue to a codebase's complexity. It's level of complexity has a lot of impact. Partially it has impact on how difficult it is to comprehend the system and make a change.
That's why people want less lines of code. In theory, less lines of code is less complex, and there is less room for error. I'm not sure that knowing that upfront is terribly useful for anything other than estimation, and planning.
For example: Supposed I have a project and on cursory examination I realize that the matter will involve modifying as many as 1000 lines of code within an application that has 10,000 lines. I know that this project is likely to take longer to implement, be less stable, and take longer to debug and test.
It's also extremely useful for understanding the scope of change between two builds. I wrote a little program that will analyze the scope of change between any two SVN revisions. It will look at a unified diff, and from it, figure out how many lines were added, removed, or changed. This helps me know what to expect in the testing and QA that follows a new build. Basically, bigger numbers of change mean that we need to watch that build closer, put it through full regression testing, etc..