Maybe engineer A has a easy feature to do. Lots of lines of code but it's smooth sailing. Another engineer, B, has a tricky bug fix to do, which requires him to read documentation, navigate the fode, reproduce the issue, until he published a fix with a handful of lines of code.
Who's the better engineer, A or B?
Even if we consider the average over time, one may be getting more tricky features than other. Or spending time in tasks such as hiring, mentoring, etc, which is worth a lot to companies.
For example, I worked a .NET project with a central form that had close to 30K lines of code. This was 10x in comparison with anything else in the app. This is clearly a "whale" of a problem.
The lines-of-code comparison made it much easier for non-technical staff to now understand why this "one form" (really dozen of different functions contained in a single form) was troublesome in terms of fixes, enhancements etc. and also why no one wanted to touch it.
You want to aim for a plane with the right weight, but you only know what that is by working out the entire design. Similarly you want to aim for the right number of lines in your code base, but you can only know what that is by working out the entire design.