The size is impressive relative to other kernels. A line of kernel code is much more expensive to develop than a line of application code. Of course, size is not be best metric by which to judge a project; it's always better to have more capability with less code if you can manage it. For its size Linux supports quite a wide variety of architectures and add-on hardware. Also, a great deal of effort goes into keeping the kernel codebase maintainable, which is more likely to manifest as lines of code removed rather than added.

Linux is the only kernel in the world with wide-ranging hardware support (due to its development policy). Everything else is either orders of magnitude more niche and only supports a tiny subset of hardware, or has a stable ABI and relies on out of tree drivers almost exclusively (Windows). Nevermind architecture support.

No given person is ever actually running most kernel code. If you took only lines compiled into the core on an average system plus the line count of currently loaded modules, you'd come up with a much smaller number.

A Google dev once told me that every day they write as much code as the whole kernel contains.

A quick math tells us that every employee (that includes non-technical people) of Google would have to write around 200 lines of code per day, which seems completely implausible in a company with a heavy software development process.

The order of magnitude is off but the scale is still much, much higher. I think they have billions of lines of code.

maybe if you also count tests, that's not very unreasonable.