Your first mistake is assuming that COBOL code was written in the 80s and untouched since then. People are still adding to COBOL code even today, and the language itself is still evolving (the newest COBOL spec was in 2014).

> That's where most code ends up getting written.

That's where most of the easy code to find and count gets written. But there is much more code that's outside of user-facing applications. Operating systems and drivers are relatively small, but have a much higher fraction of utilization since you're always using them. Embedded code is massive--not just the obvious things such as your car or airplanes, but also things like the microcontroller in your disk drive, the bluetooth controller for your headphones, your refrigerator, your microwave. There's the business applications: billing, payroll, corporate intranet, not to mention things such as scheduling the automated builds and tests or the management of releases for all of those applications. It's easy to forget that all of that stuff exists if you never work on it, and it's especially easy to think that it can't be that large.

If you avoid double-counting libraries (which is how I interpret the first number), then applications become a lot smaller because so much of applications is hooking together libraries. This is particularly true of non-app-y JS. By contrast, a lot of the business backend application logic (particularly for things such as payroll) is essentially 100% custom-implemented, so a much smaller fraction of it is common libraries. On pretty much any other metric of code use, though, such applications become far smaller in importance.