Any line-based metric should be suspect, but 'delta-SLOC' is probably the least bad. I would count added lines and removed lines separately, so a +50,-150 patch would be 200 ΔSLOC.
This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change. A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC at all, depending on what that peer is up to, but the first of these is definitely changing the codebase more than the second, during the measured time span.
There is I believe a specific context where removal is good and others where that is not the right measure
I'm working on some java 8 cide that was written by folks still living in java 1.4 land, lots of opportunities there to reduce 20 lines into 3 (plus those devs kinda insisted on doing things in painful and unnecessary ways). In parallel, I'm working on a Greenfield project. Even on the Greenfield, there are times when negative code added is good. Not all programmer activities are equal
It's like measuring gas consumption during emergency braking, during acceleration, and during normal highway cruising. Sometimes it firs, or kinda fits, other times it's just the wrong metric. Programming is not a homogeneous activity
ΔSLOC is just a metric, and what it measures is change to the codebase. Yes, some changes are very important, and others nearly trivial, so it's quantitive because a qualitative metric is a contradiction.
It certainly means different things in different contexts, if it's even meaningful at all. My claim is that +SLOC is entirely meaningless outside of the tautology that it measures what it is, where ΔSLOC is in fact informative about change to the software, albeit not perfectly so.
My hope is to convey more texture here, that programming is more than just one thing. EG: "Today I was mostly debugging". That could have its own measures. I think in large part the measures of programming productivity are often too reductive, the measure is incomplete or tries to measure "programming" rather than its _many_ distinct sub-activities.
This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change. A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC at all, depending on what that peer is up to, but the first of these is definitely changing the codebase more than the second, during the measured time span.