Reason 1 : Because without printing it out you can not weigh it.
When I was an university, there was a myth that some lazy teachers (I don't know the technical terms for the roles), would weigh your reports, and give a grade base on that. I heard of one student that handed in some work with a load of blank paper attached, and got a good grade.
Reason 2 : To see how complex it is.
I remember a story by Michael Jackson, about judging how brilliant some one is. I will include the last 3 paragraphs here.
“Terrific,” I mumbled respectfully. I got the picture clearly. Fred
as Frankenstein, Fred the brilliant creator of the uncontrollable
monster flowchart. “But what about Jane?” I said. “I thought Jane was
very good. She picked up the program design ideas very fast.”
“Yes,” said the DP Manager. “Jane came to us with a great reputation.
We thought she was going to be as brilliant as Fred. But she hasn't
really proved herself yet. We've given her a few problems that we
thought were going to be really tough, but when she finished it turned
out they weren't really difficult at all. Most of them turned out
pretty simple. She hasn't really proved herself yet — if you see
what I mean?”
I saw what he meant.
Reason 3 : To see how complex it is.
Over complex code is bad, see in working out the final grade, the number of lines of code, goes some ware in the denominator.
Reason 4 : Looking for outliers
This is the only one that would make any sense, but people do a lot of thinks that don't make sense.
Because they knew how many line it should take, and they were looking for statistical outliers. If the line count is way off then it is a sign of a problem.
In any case, I could not count lines of code. Even looking for outliers is throught with dangers.
A few years back, when I was a software engineer. Some one introduced a software metrics tool. It measured Mccabe complexity (various complexities of the code). It was a good tool, and very useful. You could find parts of the code that were un-usual. Often you could find bugs by examining these parts of the code.
One day the head of QA came to me, screaming. He was waving a bit of paper with the results of the tests. It showed that a module, that I had written had a complexity for class dependency that was off the chart. I pointed out that all the other complexity metrics were close to zero. He screamed, "but what about this one". I pointed out, that this class was a factory, it was its job to own this complexity, because it would be worse to have it spread about. I said "if it was spread about, then the metrics would not find it, ..." he interrupted "then spread it about". I continued "... but then the code would be much more complex." -- He looked at me blackly.
We stopped using the tool shortly after that. A shame. It was a good tool. It helped us find bugs. However it did not tell us where the bugs were. It told us what the probably bug density is, if you knew how to read it.
So yes lines of code can be useful, but only as a statistical tool.