There's a lot of answers here that address the technical pros and cons of keeping LOC down and whether or not it's a meaningful quality software metric. That's not what this question is about. What it's about is how to deal with management that insists on a naive dogmatic adherence to a particular coding rule of thumb.
Sadly, it's fairly common for people to latch onto things that are good advice when used in the proper context and applied pragmatically, take them out of that context and apply them dogmatically while failing to appreciate the issues the advice exists to mitigate in the first place.
The intent of advice regarding keeping LOC down is to avoid the creation of methods that try to do too much in one go, and to discourage the creation of "god classes", which know too much about aspects of a design that aren't their direct responsibility and which all other classes in the system are dependant on. Another advantage of shorter code is that it's more readable, though as you've pointed out, you can overdo it to the point where readability actually starts to suffer.
There are obvious advantages to low LOC counts (small methods fit into your head more easily than big ones, fewer things in the code means fewer things to go wrong, etc), but it is also subject to the law of diminishing returns. Refactoring a 150 line method into a number of 20 line methods is a much bigger win than refactoring a 10 line method into a 7 line method.
When such refactoring comes at the expense of some other facet of good software design (such as readability) then you have reached a point where you can justify not doing it. Removing variables that give context to what the code means and replacing them with literals that don't is a very very bad thing to do. Good code has almost no literals in it. However, these variables (and named constants) are lines of code that don't directly contribute to the program and so if LOC is being worshipped as some kind of god then such clarification lines are in great peril of being pruned for a quick win and some misguided praise from management.
I believe you're smart enough to realise this, in fact that's pretty much the thrust of your original question. The problem isn't your understanding of when code reduction is good and when it's not, the problem is dogmatism in applying what is normally a reasonable practice indiscriminately.
I would recommend taking the time to chat with your management, explaining your position and why you feel that what you're being asked to do harms the code rather than helps it. Try to avoid being confrontational, but do try to remain rational and calm during such a discussion. It's important that your management understands that programming is a pragmatic activity, and best practice advice is only useful if it's applied in a pragmatic way. Best practice is written in a book, not carved in stone, and when it conflicts (short code versus readable code) then it's up to the programmer to apply their judgement as to which best practice to follow. Hopefully they are reasonable people who appreciate input such as this.
You also need to be a bit brave, because if you're being pressured to reduce LOC where you think it's unnecessary or inappropriate then it's only natural that you'd make the change anyway for the sake of a quiet life. You need to resist doing this, and you have to "own" that decision. In a situation where management are reasonable you shouldn't have to adhere to their guidelines exactly, but you should be able to justify any circumstances where you don't.
Sadly, people can be irrational, especially when it comes to people lower on the pecking order questioning their decisions and the rules they've imposed on you. They may choose not to be reasonable. You need to be prepared for that too. If you can demonstrate cases where the LOC best practice comes into direct conflict with other best practice and why that's hurting the product, and if you can do it in portions of the code base for which they had little or no personal involvement (so it doesn't seem like a personal attack on their work or work they supervised) then this may help bolster your argument. Again, you have to be prepared to justify yourself in a calm, rational way and be able to "own" the arguments you're making.
Provided your management are reasonable people then they must appreciate that what you're saying has merit if you can provide evidence to back your claims up.
s/\n/ /g) it doesn't mean it will be even remotely readable