Yeah, whoever told you that has never had the sinking feeling of digging in to a 300 or 1000 LOC function with a pretty refactor in mind only to see just how much of the system relies on that one function. It's really only an issue if you try to be diligent about testing the work you produce, in which case that little refactor could cost your team a week or a month of additional testing while they verify that you didn't break anything.
Or you could sneak one more little if statement or some copy/paste in there to fix it instead, and add a little comment that says "If you modify this line, please verify that your change doesn't impact Line XXX of file FFFF as well." And then you're done in less than a day and have saved a huge amount of testing.
This is especially problematic in machine-control code.
I've seen code from an otherwise highly capable developer that contained 1000+ LOC functions. When asked why he couldn't do a refactor the answer boiled down to fear. When the only real way to test the code is by physically running a machine through a number of scenarios, many of which are difficult at best to recreate, you become very reluctant to refactor or clean it up.
Like all problems, it's best to nip it in the bud before things get that far out of line.
Line numbers might not stay static. Perhaps referring to a particular function or variable might be better, as well as explaining what it might impact? That way, one can jump to the location, then inspect it to see if the potentially-impacting behaviour still exists.
Definitely useful in the case where it's near-to-impossible to DRY up something, though. Sadly, the limitations of an industrial C environment have led my code to contain a lot of annoying 'If you add something here, make sure to add it to X struct and Y function' comments.
Or you could sneak one more little if statement or some copy/paste in there to fix it instead, and add a little comment that says "If you modify this line, please verify that your change doesn't impact Line XXX of file FFFF as well." And then you're done in less than a day and have saved a huge amount of testing.