KLOC can be a useful productivity metric to track at an individual developer level, given the developer works in the same domain for an extended period of time, and has the professional and skill level maturity not to game it. That relies on management that doesn't try to aggregate it or compare it in an apples to oranges fashion across developers, domains or (worse) languages.

The problem is that this is a theoretical scenario which rarely comes up in reality. The developers operating at the skill and maturity level where tracking their individual productivity and quality can be done well, generally are not the developers who really need these types of measures, and they usually aren't left grinding on the same domain for the years required to have enough data to do anything useful with it.

It is kind of a catch 22. The situations where tracking and gaining insight from KLOCs would help (mature/skilled devs working on the same thing over and over for years...doesn't happen much), are not the situations where it is most needed (projects with hundreds of relatively inexperienced/immature developers and managers)

The result is it is applied to disastrous effect in situations where immature managers glom onto it as a silver bullet for managing the unmanageable.