This is all very informal, but I heard someone say a good programmer can reasonably maintain about 20,000 lines of code. Whether that is 20,000 lines of assembler, C, or some high-level language doesn't matter. It's still 20,000 lines. If your language requires fewer lines to express the same ideas, you can spend more time on stuff that otherwise would go beyond those 20,000 lines.
A 20,000-line Python program would probably be a 100,000-line Java or C++ program. It might be a 200,000-line C program, because C offers you even less structure. Looking for a bug or making a systematic change is much more work in a 100,000-line program than in a 20,000-line program. For smaller scales, it works in the same way. A 500-line program feels much different than a 10,000-line program.
I've seen this idea crop up in other places over the last week. The idea it expresses--that we have finite carrying capacity, and can get more things done quicker if we can avoid having to pack excess, low-value "stuff"--is a powerful meme. Non-technical managers can understand it.
But there's a dark side. If things get too compressed, if the abstractions are too dense, a body of code can be just as hard to debug. I suspect that there are "appropriate" densities for both code and abstractions, and perhaps appropriate mixes of weak vs. strong abstractions, but that's about as far as I've thought it through.