All of today's software is built on millions of lines of code. This isn't much of a problem when it's hidden away behind a good abstraction. Being written in another language forces the API to be documented well enough so you don't need to go deeper: "native code", "kernel code", "part of the browser".
Crappy million-line Java apps are generally crappy not due to raw line count but rather due to leaky abstractions and badly designed APIs, so you do have to navigate through a lot of that code.
I sometimes wonder if programmers instinctively overcomplicate things in interest of collective job security. Some of the stuff I've seen in (particularly awful) Java code bases is perplexing to the point where it seems intentional.
It's more likely the natural entropy of code - it's easy to add stuff to a system in a way that makes it more messy; and if the system already is a big mess, then it's much harder to do non-messy additions and the bigger mess it is, the harder it is to start cleaning it up.
I refer to this as the "spaghetti law of attraction". The burden of refactoring things gets higher and higher and no one wants to touch it. So they just add another try-catch block and do some side effect and get the PR merged.
It is also a question of management, it is easier to motivate adding new features instead of keeping thing nice and tidy. Especially as finding good abstractions are very hard and time-consuming.
Writing clear and as-simple-as-possible code is one of the most difficult parts of programming, one of the hardest skills to learn. In fact, many programmers don't ever learn it. Some do not even realize it's a problem.
I could talk about people unprepared for the jobs they do, and companies and managers setting unrealistic deadlines, having unrealistic expectations, etc. But I think most often than not, the issue is that to really build good code, you need to have a lot of experience and plan and design really well from the start. And simply, most companies and products start as they can. If you start with a deficient codebase, trying to fix that later under heavy budget and time constraints is pretty much impossible, and it's so accepted that some people believe it's the normal way to work.
And even with proper design, clear perspective, and good programmers, you still have to be lucky that no one higher up the ladder imposes decisions that f*ck up all the good work done. There are a few factors more.
What I mean is that you might find all kinds of people, but in general, for those of us who care about what we are doing it's the exact opposite. We consciously try really hard to keep code as simple as possible.
Crappy million-line Java apps are generally crappy not due to raw line count but rather due to leaky abstractions and badly designed APIs, so you do have to navigate through a lot of that code.