It's just a result of ruthless optimization. Management is always pushing us devs to optimize the metrics that are easiest to measure, and there are plenty of online tools that will score a site based partly on the file sizes for JS, CSS and even HTML.
Right now, we're running the whole response through something like an optimizing compiler stack (Webpack, with lots of plugins and some custom modules). It renames everything to the shortest possible name, eliminates code that will never execute, inlines CSS into the <head> and <body> to reduce HTTP requests, splits the code into large bundles that can be cached forever and a small bundle that will be updated nearly every workday, stuff like that.
I'm afraid we're at the point now where a modern HTML response requires advanced tools in order to make it legible to a human. For that, I apologize, no sarc, we are aware of the loss of culture that is happening. There is some pushback happening, in the form a ruthless minimalism (plain HTML, no css, no JS), but good luck demonstrating the beauty of that to the UX team.
If it's any consolation, these advanced tools are built into FF and Chrome; just right click, inspect element, and look for associated JS handlers. The browser can clean up the code formatting for you, although the names will still be arbitrary. Set a breakpoint on an interesting statement, trigger (or manually fire) the action you followed to get there, and explore the values that are in scope at that point. Watching the values change will often tell you more than reading the code itself, when the names are meaningless.
As for the inconsistency mentioned by my sibling, that sounds a little broken. One of the things we do with the Webpack stack, is specialize the code for known browsers, by eliminating the browser-specific stuff that isn't needed for the current visitor; w3m and wget are not high priority targets :/