On one level, they are right - less code is better.Another answer quoted Gate, I prefer:
“If debugging is the process of removing software bugs, then programming must be the process of putting them in.”– Edsger Dijkstra
“When debugging, novices insert corrective code; experts remove defective code.”– Richard Pattis
The cheapest, fastest, and most reliable components are those that aren’t there. - Gordon Bell
In short, the less code you have, the less can go wrong. If something isn't necessary, then cut it.
If there is over-complicated code, then simplify it until the actual functional elements are all that remain.
What is important here, is that these all refer to functionality, and only having the minimum required to do it. It doesn't say anything about how that is expressed.
What what you are doing by attempting to have clean code isn't against the above. You are adding to your LOC but not adding unused functionality.
The end goal is to have readable code but no superfluous extras. The two principles should not act against each other.
A metaphor would be building a car. The functional part of the code is the chassis, engine, wheels... what makes the car run. How you break that up is more like the suspension, power steering and so on, it makes it easier to handle.You want your mechanics as simple as possible while still performing their job, to minimise the chance of things going wrong, but that doesn't prevent you from having nice seats.
